Re: [git pull] new mount API

[Al Viro <viro@ZenIV.linux.org.uk>]

On Fri, Aug 24, 2018 at 09:25:58PM +0200, Miklos Szeredi wrote:
> On Fri, Aug 24, 2018 at 7:43 PM, Andy Lutomirski <luto@kernel.org> wrote:
> > On Fri, Aug 24, 2018 at 10:10 AM, David Howells <dhowells@redhat.com> wrote:
> >> Andy Lutomirski <luto@amacapital.net> wrote:
> >>
> >>> Hmm. Is it that case in the current patchset that you can do CMD_CREATE and
> >>> reconfigure the result and some *other* existing mount will change?  If so,
> >>> that’s rather unfriendly to users.
> >>
> >> The default behaviour has to be the same as mount(2).
> 
> This is rubbish.  Anyone wanting the mount(2) behavior can use mount(2).
> 
> About exclusive create: can't we just look at the active reference
> count of the superblock returned by ->get_tree() (if it's one, we are
> the only users, i.e. the create was exclusive)?

Let me get it straight - your default behaviour would routinely refuse NFS mount
simply because somebody has already mounted from the same server?

The main reason for keeping existing semantics is very, very simple: nobody
has offered a sane replacement.  For all warts (and I admit that policy
re sharing turned out to be rather bad for any kind of situation with
non-cooperative admins - in partial defense, back in 2000/2001 when it was
done anybody talking about something like userns would've gotten laughed at,
for a lot of good reasons) mount(2) semantics is defined *and* needs to be
supported anyway.

All suggested "better replacements" were bloody problematic.  Sure, we'll need
to sort that out, but again, why the hell tie that to untangling the sodding
mount(2) ABI?