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

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

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