Date: Tue, 23 Oct 2007 10:39:03 +0000 (UTC) From: Bruce Evans <bde@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/fs/msdosfs msdosfs_vfsops.c Message-ID: <200710231039.l9NAd34X036389@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710231039.l9NAd34X036389>