Bug 15063

---------- Forwarded message ----------
Date: 23 Nov 1999 15:39:25 +0100
From: assar@stacken.kth.se
To: gnats-admin@FreeBSD.org
Cc: freebsd-bugs@FreeBSD.org
Subject: Re: kern/15063: "indirect pointer mismatch" in softdep

some additional information:

the file system being written to was / and as far as I can tell it
wasn't full at the moment.  a little bit of cut-n-paste from gdb:

(kgdb) f 20
#20 0xc023d239 in ffs_fsync (ap=0xc840df88) at ../../ufs/ffs/ffs_vnops.c:210
(kgdb) p *ap
$3 = {a_desc = 0xc02f5920, a_vp = 0xc83f9e80, a_cred = 0xc073b900, 
  a_waitfor = 3, a_p = 0xc83ff800}
(kgdb) p a_vp
No symbol "a_vp" in current context.
(kgdb) p ap->a_vp
$4 = (struct vnode *) 0xc83f9e80
(kgdb) p *$
$5 = {v_flag = 2105344, v_usecount = 1736, v_writecount = 0, v_holdcnt = 110, 
  v_id = 60, v_mount = 0xc0b09400, v_op = 0xc0b2cc00, v_freelist = {
    tqe_next = 0xc83f9d40, tqe_prev = 0xc83f9fdc}, v_mntvnodes = {
    le_next = 0xc83f9f20, le_prev = 0xc83f9d64}, v_cleanblkhd = {
    tqh_first = 0xc34679c0, tqh_last = 0xc34457f8}, v_dirtyblkhd = {
    tqh_first = 0xc3468548, tqh_last = 0xc34a28c8}, v_synclist = {
    le_next = 0x0, le_prev = 0xc0b18664}, v_numoutput = 1, v_type = VBLK, 
  v_un = {vu_mountedhere = 0xc0b68b80, vu_socket = 0xc0b68b80, vu_spec = {
      vu_specinfo = 0xc0b68b80, vu_specnext = {sle_next = 0x0}}, 
    vu_fifoinfo = 0xc0b68b80}, v_lease = 0x0, v_lastw = 0, v_cstart = 0, 
  v_lasta = 0, v_clen = 0, v_object = 0xc03291c0, v_interlock = {
    lock_data = 0}, v_vnlock = 0x0, v_tag = VT_UFS, v_data = 0xc0b66f00, 
  v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0xc0b2bac0, 
    tqh_last = 0xc0b2bad0}, v_dd = 0xc83f9e80, v_ddid = 0, v_pollinfo = {
    vpi_lock = {lock_data = 0}, vpi_selinfo = {si_pid = 0, si_flags = 0}, 
    vpi_events = 0, vpi_revents = 0}}
(kgdb) p $.v_mount
$6 = (struct mount *) 0xc0b09400
(kgdb) p *$
$7 = {mnt_list = {tqe_next = 0xc0b5ca00, tqe_prev = 0xc0302964}, 
  mnt_op = 0xc030cbe0, mnt_vfc = 0xc030cc20, mnt_vnodecovered = 0x0, 
  mnt_syncer = 0xc83f9840, mnt_vnodelist = {lh_first = 0xc8e47600}, 
  mnt_lock = {lk_interlock = {lock_data = 0}, lk_flags = 17825792, 
    lk_sharecount = 1, lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 20, 
    lk_wmesg = 0xc02c46c2 "vfslock", lk_timo = 0, lk_lockholder = -1}, 
  mnt_flag = 2117632, mnt_kern_flag = 0, mnt_maxsymlinklen = 60, mnt_stat = {
    f_spare2 = 0, f_bsize = 1024, f_iosize = 8192, f_blocks = 39647, 
    f_bfree = 12503, f_bavail = 9332, f_files = 10110, f_ffree = 9006, 
    f_fsid = {val = {938346654, 1041415783}}, f_owner = 0, f_type = 2, 
    f_flags = 2117632, f_syncwrites = 5, f_asyncwrites = 138, 
    f_fstypename = "ufs", '\000' <repeats 12 times>, 
    f_mntonname = "/", '\000' <repeats 88 times>, 
    f_mntfromname = "/dev/wd0s1a", '\000' <repeats 78 times>}, 
  mnt_data = 0xc0b5cc00, mnt_time = 943360985, mnt_iosize_max = 126976}
(kgdb)

Comment 2 Poul-Henning Kamp 1999-12-22 16:39:46 UTC

Responsible Changed
From-To: freebsd-bugs->mckusick

Kirks department. 

Comment 3 Kirk McKusick 2000-01-11 21:10:01 UTC

State Changed
From-To: open->closed

A fix was applied to sys/ufs/ffs/ffs_balloc.c. The checkin comment was: 

revision 1.25 
date: 2000/01/11 08:27:00;  author: mckusick;  state: Exp;  lines: +14 -4 
The only known cause of this panic is running out of disk space. 
The problem occurs when an indirect block and a data block are 
being allocated at the same time. For example when the 13th block 
of the file is written, the filesystem needs to allocate the first 
indirect block and a data block. If the indirect block allocation 
succeeds, but the data block allocation fails, the error code 
dellocates the indirect block as it has nothing at which to point. 
Unfortunately, it does not deallocate the indirect block's associated 
dependencies which then fail when they find the block unexpectedly 
gone (ptr == 0 instead of its expected value). The fix is to fsync 
the file before doing the block rollback, as the fsync will flush 
out all of the dependencies. Once the rollback is done the file 
must be fsync'ed again so that the soft updates code does not find 
unexpected changes. This approach is much slower than writing the 
code to back out the extraneous dependencies, but running out of 
disk space is not expected to be a common occurence, so just getting 
it right is the main criterion. 

PR:             kern/15063 
Submitted by:   Assar Westerlund <assar@stacken.kth.se>