cvs commit: src/sys/fs/msdosfs msdosfs_vfsops.c

[Bruce Evans]

bde         2007-10-23 10:39:03 UTC

  FreeBSD src repository

  Modified files:
    sys/fs/msdosfs       msdosfs_vfsops.c 
  Log:
  Forced commit to note that rev.1.179 has the following fixes in addition to
  the ones mentioned in its log message:
  
  For mount-update from rw to ro:
  - don't misuse the MNT_FORCE flag to break error handling for mark volume
    to clean.
  - mark volume back to dirty if g_access() failed (not just if mark volume
    to clean failed).
  - clear pm_fmod on success.  pm_fmod is bogus, since it is only used to
    cause a panic in unreachable code when we forgot to clear it here, but
    something like it will be needed.
  
  For mount-update from rw to ro and from ro to rw:
  - don't forget to lock mp when changing mp->mnt_flag.  Giant locking
    may make this unnecessary, but it is simpler to copy what ffs does.
    Most of the style changes are near here, to copy ffs's cleaner code.
  
  For unmount:
  - don't misuse the MNT_FORCE flag to break error handling for mark volume
    to clean.   Failure of markvoldirty() is similar to failure of
    ffs_subupdate() in ffs, and ffs has never used MNT_FORCE to ignore
    the corresponding error.  MNT_FORCE for unmount _should_ force the
    unmount to succeed, but forcing away of write errors has never been
    supported.
  - explicitly return 0 instead of `error' in msdosfs_unmount() after
    committing to success.  This is now just a style fix.  With errors from
    markvoldirty() ignored in the MNT_FORCE case, any error in markvoldirty()
    caused a nonzero `error' to be returned despite committing to success.
    Upper layers soon paniced trying to back out of the committed unmount.
  
    This bug used to be present in another form in most file systems.
    VOP_CLOSE() was called after committing to success, so it was necessary
    to force the VOP_CLOSE() to succeed.  This was not done; instead,
    VOP_CLOSE()'s error code was returned to upper layers so upper layers
    soon paniced if VOP_CLOSE() failed.  I saw this panic only with a buggy
    device driver with a missing close method, but VOP_CLOSE() can easily
    fail in theory, with errors like EDQUOT and EIO for unwriteable output.
  
    Now the bug has moved.  g_vfs_close() is called instead of VOP_CLOSE(),
    and it returns void so unmount vops cannot even detect errors in it.
    Hopefully, errors in it only occur when there are other bugs.  E.g.,
    with the MNT_FORCE bug in msdosfs_close(), when markvoldirty() in
    umount failed due to the bugs in mount-update, and when this was the
    only write error, g_vfs_close() was reached despite the write error
    being detected earlier; it found one unwriteable buffer which it can
    only report via printf; then after fixing the panic, umount(2)
    "succeeded" but the unwriteable buffer was left in the buffer cache
    and/or VMIO object to spam the console with printfs about failed
    write attempts, until the next rw mount when the write succeeds,
    possibly clobbering different media.
  
  Revision  Changes    Path
  1.181     +0 -0      src/sys/fs/msdosfs/msdosfs_vfsops.c