[patch] nmount ro, rw and negated option handling
Jaakko Heinonen
jh at FreeBSD.org
Fri Jan 14 12:40:02 UTC 2011
Hi,
Currently nmount(2) allows a mount point to have "ro", "rw", and "noro"
string options concurrently active. This can cause erratic behavior
demonstrated by this example:
1. Have mountd(8) running.
2. # mdconfig -a -t vnode -f ufsimg
3. # mount -o ro,rw /dev/md0 /mnt
After these steps the mount point has string options "ro", "rw" and
"noro" active but the MNT_RDONLY flag is not set. Eventually this will
lead to "ffs_sync: rofs mod" (or similar) panic because the ffs code
marks the file system read-only due to the "ro" string option.
(MNT_RDONLY flag is used in most places for read-only check.)
I wrote a patch to do following changes:
- vfs_equalopts() now recognizes "ro" and "rw" as equal options
- vfs_mergeopts() uses vfs_sanitizeopts() to merge options. This ensures
that if the same option shows up several times (negated or not), only
the last one is taken in account. There is still a problem when for
example option "foo" and "nofoo" are merged: the "nofoo" option will
become an active option. This is not a regression however and
currently I don't know an easy way to solve this because the list of
valid options is not available in vfs_mergeopts().
- vfs_donmount() always converts "norw"/"rdonly" to "ro" and "noro" to
"rw". Thus the mount point will always have either "rw" or "ro"
option. I haven't seen any in-tree file system to test for "noro" but
at least ZFS tests for "rw". That's why I chose "rw" instead or
"noro".
The patch is available here:
http://people.freebsd.org/~jh/patches/nmount-ro-rw.diff
Reviews and testing would be appreciated.
Here are some references to bug reports which the patch attempts to
resolve:
http://lists.freebsd.org/pipermail/freebsd-current/2009-September/thread.html#11385
http://lists.freebsd.org/pipermail/freebsd-questions/2009-August/204124.html
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/133614
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/150206
--
Jaakko
More information about the freebsd-hackers
mailing list