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.

This commit is contained in:

bde

2007-10-23 10:39:03 +00:00

parent 7269c46635

commit ff02cfc2bd

Forced commit to note that rev.1.179 has the following fixes in addition to

Diff Content Not Available