From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 00/26] Mount writer count and read-only bind mounts Date: Sat, 30 Jun 2007 10:57:44 +0100 Message-ID: <20070630095744.GA23214@infradead.org> References: <20070622200303.82D9CC3A@kernel> <20070623095246.a9061585.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Hansen , linux-fsdevel@vger.kernel.org, hch@infradead.org, viro@ftp.linux.org.uk To: Andrew Morton Return-path: Received: from pentafluge.infradead.org ([213.146.154.40]:38653 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753555AbXF3J5r (ORCPT ); Sat, 30 Jun 2007 05:57:47 -0400 Content-Disposition: inline In-Reply-To: <20070623095246.a9061585.akpm@linux-foundation.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sat, Jun 23, 2007 at 09:52:46AM -0700, Andrew Morton wrote: > Doesn't selinux do some of this? No. > My overall reaction: owch. There's a ton of tricksy code here and great > potential for us to accidentally break it in the future by forgetting a > mnt_may_write() as the kernel evolves. And then there's the added > complexity and the added runtime overhead. Most of the code is not actually implementing per-mountpoint r/o but fixing the way we deal with mount -o remount,ro and the general writeability state of a filesystem. Theres been a huge racy window before which is fixed. And it lays the groundwork for interesting new things like the posibility for the filesystem to revert to r/o after it's not been written to for a while. There's been a plain r/o bindmounts patch from the vserver folks that's a lot smaller because it doesn't fix the problems (and actually widens them a little) > > Balance that against some pretty obscure-looking benefits and I'm > struggling to see how a merge is justifiable? It's a feature people have been asking for a long time, just about a month ago there has been a lenghty thread on the nfs list about the requirement. And it only gets more important (not to say absolutely essential) for full containers support, where you really don't want your untrusted container to able to write into the shared /usr.