From owner-freebsd-bugs@FreeBSD.ORG Mon Feb 11 14:10:02 2008 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A825A16A41B for ; Mon, 11 Feb 2008 14:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9096613C4CC for ; Mon, 11 Feb 2008 14:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1BEA27W023713 for ; Mon, 11 Feb 2008 14:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1BEA2bL023712; Mon, 11 Feb 2008 14:10:02 GMT (envelope-from gnats) Date: Mon, 11 Feb 2008 14:10:02 GMT Message-Id: <200802111410.m1BEA2bL023712@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Yar Tikhiy Cc: Subject: Re: kern/120319: fsck on read-only root fs upgrades it to read-write X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yar Tikhiy List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2008 14:10:02 -0000 The following reply was made to PR kern/120319; it has been noted by GNATS. From: Yar Tikhiy To: Jaakko Heinonen 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