From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul Menage" Subject: Re: [PATCH] Add MS_BIND_FLAGS mount flag Date: Thu, 14 Feb 2008 07:19:33 -0800 Message-ID: <6599ad830802140719l270d6fdfyd6d17806eda12a8d@mail.gmail.com> References: <47B283EB.8070209@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: viro@zeniv.linux.org.uk, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: "Miklos Szeredi" Return-path: Received: from smtp-out.google.com ([216.239.45.13]:32717 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752103AbYBNPTj (ORCPT ); Thu, 14 Feb 2008 10:19:39 -0500 Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id m1EFJYFY001929 for ; Thu, 14 Feb 2008 07:19:34 -0800 Received: from py-out-1112.google.com (pyhb50.prod.google.com [10.34.229.50]) by zps38.corp.google.com with ESMTP id m1EFJYMi023610 for ; Thu, 14 Feb 2008 07:19:34 -0800 Received: by py-out-1112.google.com with SMTP id b50so428559pyh.30 for ; Thu, 14 Feb 2008 07:19:34 -0800 (PST) In-Reply-To: Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Feb 14, 2008 at 12:30 AM, Miklos Szeredi wrote: > > For recursive bind mounts, only the root of the tree being bound > > inherits the per-mount flags from the mount() arguments; sub-mounts > > inherit their per-mount flags from the source tree as usual. > > This is rather strange behavior. I think it would be much better, if > setting mount flags would work for recursive operations as well. Also > what we really need is not resetting all the mount flags to some > predetermined values, but to be able to set or clear each flag > individually. This is certainly true, but as you observe below it's a fair bit more fiddly to specify in the API. I wasn't sure how much people recursive bind mounts, so I figured I'd throw out this simpler version first. > > For example, with the per-mount-read-only thing the most useful > application would be to just set the read-only flag and leave the > others alone. > > And this is where we usually conclude, that a new userspace mount API > is long overdue. So for starters, how about a new syscall for bind > mounts: > > int mount_bind(const char *src, const char *dst, unsigned flags, > unsigned mnt_flags); The "flags" argument could be the same as for regular mount, and contain the mnt_flags - so the extra argument could maybe usefully be a "mnt_flags_mask", to indicate which flags we actually care about overriding. What would happen when an existing super-block flag changes to become a per-mount flag (e.g. per-mount read-only)? I think that would just fit in with the "mask" idea, as long as we complained if any bits in mnt_flags_mask weren't actually per-mount settable. Being able to mask/set mount flags might be useful on a remount too, since there's no clean way to get the existing mount flags for a mount other than by scanning /proc/mounts. So an alternative to a separate system call would be a new mnt_flag_mask argument to mount() (whose presence would be indicated by a flag bit being set in the main flags) which would be used to control which bits were set cleared for remount/bind calls. Seems a bit wasteful of bits though. If we turned "flags" into an (optionally) 64-bit argument then we'd have plenty of bits to be able to specify both a "set" bit and a "mask" bit for each, without needing a new syscall. Paul