Re: kern/41189: kernel panic xen dom0 using mke2fs & WAPBL

[Andrew Doran <ad%netbsd.org@localhost>]

The following reply was made to PR kern/41189; it has been noted by GNATS.

From: Andrew Doran <ad%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/41189: kernel panic xen dom0 using mke2fs & WAPBL
Date: Fri, 17 Apr 2009 20:51:04 +0000

 I don't know exactly what is happening in this case but there are at least
 two issues that I see. Ok so ffs_full_fsync() is called for the vnode
 representing /dev/sd0m:
 
 (1) WAPBL processing should happen on this vnode, because the corresponding
 inode is from a logging file system. However it represents a block device,
 and so the call to wapbl_vptomp() ignores the important fact that it's from
 a logging FS and returns NULL. We skip the WAPBL block.
 
 (2) Since we are not doing the logging update in ffs_full_sync(), we descend
 into the regular UFS case. This flushes any delayed writes resulting from
 block I/O from userspace (or a mounted file system) to the device. This
 happens correctly. Note that if (1) is fixed naively, this will cease to
 happen. In theory this should flush the buffers for spec_close(). Once this
 is done, we incorrectly do the inode update as if there was no logging.
 
 Some background information. ffs hangs its dirty buffers in two places:
 
 - vp->v_dirtyblkhd
  
   VREG/VDIR: indirect blocks, to track per-inode space allocation
   VBLK: dirty blocks for a block device
   Others: not used
 
 - VTOI(vp)->i_ump->um_devvp->v_dirtyblkhd
 
   All other metadata, e.g. on-disk inodes.
 
 Since block devices don't have indirect blocks, there shouldn't be a clash.
 The whole thing is a big mess. We could fix a slew of bugs once and for all
 with devfs. It would greatly simplify this crud. In the meantime I am going
 to crack open a beer. :-)