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

[christos%zoulas.com@localhost (Christos Zoulas)]

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

From: christos%zoulas.com@localhost (Christos Zoulas)
To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, 
        gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
jdwhite%iastate.edu@localhost
Cc: 
Subject: Re: kern/41189: kernel panic xen dom0 using mke2fs & WAPBL
Date: Fri, 17 Apr 2009 17:19:12 -0400

 On Apr 17,  8:55pm, ad%netbsd.org@localhost (Andrew Doran) wrote:
 -- Subject: Re: kern/41189: kernel panic xen dom0 using mke2fs & WAPBL
 
 | 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. :-)
 
 I think that there are differences in the way that the wait or no wait flag
 is computed in many places and I believe that they should be consistent. Like:
 
 error = ffs_update(vp, NULL, NULL,
     (ap->a_flags & FSYNC_WAIT) ? UPDATE_WAIT : 0);
 
 vs.
 error = ffs_update(vp, NULL, NULL,
     ((ap->a_flags & (FSYNC_WAIT | FSYNC_DATAONLY)) == FSYNC_WAIT)
     ? UPDATE_WAIT : 0);
 
 christos