Date: Mon, 11 Feb 2008 14:10:02 GMT From: Yar Tikhiy <yar@comp.chem.msu.su> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/120319: fsck on read-only root fs upgrades it to read-write Message-ID: <200802111410.m1BEA2bL023712@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/120319; it has been noted by GNATS.
From: Yar Tikhiy <yar@comp.chem.msu.su>
To: Jaakko Heinonen <jh@saunalahti.fi>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/120319: fsck on read-only root fs upgrades it to read-write
Date: Mon, 11 Feb 2008 17:04:43 +0300
On Thu, Feb 07, 2008 at 11:53:23PM +0200, Jaakko Heinonen wrote:
> On 2008-02-07, Yar Tikhiy wrote:
> > > This happens because the kernel doesn't set the "ro" mount option
> > > initially for mounts in vfs_mountroot_try() (vfs_mount.c). ffs_mount()
> > > remounts a file system as read-write if the "ro" option is missing.
> >
> > You've hit the nail on the head! Now the question is: Which of the
> > two functions should be fixed after all? Some parts of the system
> > seem to rely solely on MNT_RDONLY to get a read-only mount, so it
> > might be wrong for ffs_mount() to look for the "ro" option even if
> > MNT_RDONLY is set in the mount flags. Any ideas?
>
> Seems that msdosfs, ext2fs, nfs and zfs also rely on "ro" on remount. So
I bet they just had the code copied from the FFS driver.
> changing ffs_mount() means changes for other file systems too to keep
> their behavior identical. For me the vfs_mountroot_try() approach seems
> logical because that unifies behavior of mount(8) and
> vfs_mountroot_try().
I'm afraid that handling MNT_RDONLY versus the "ro" option in the kernel
hasn't been really consistent since the introduction of nmount(2). Why
should a caller of nmount() or vfs_donmount() have to specify both MNT_RDONLY
and the "ro" option? And, according to the nmount(2) manpage:
MNT_RDONLY The file system should be treated as read-only; even the
super-user may not write on it. Specifying MNT_UPDATE
without this option will upgrade a read-only file system
to read/write.
In fact, it isn't 100% true as the "ro" option is dup'ed to the
MNT_RDONLY flag in vfs_donmount(); i.e., it's OK to specify "ro"
only. Then why is it wrong to specify MNT_RDONLY only? Now I think
I'd rather fix vfs_donmount() so that it adds the "ro" option if
it isn't there but MNT_RDONLY is set. The function already does
so if the "rw" option is specified. But IMHO all this is dirty
hackery, whose need results from non-conformity in nmount(2) framework
semantics.
--
Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802111410.m1BEA2bL023712>