From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:60952 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726277AbeHXX1X (ORCPT ); Fri, 24 Aug 2018 19:27:23 -0400 Date: Fri, 24 Aug 2018 20:51:12 +0100 From: Al Viro To: Miklos Szeredi Cc: Andy Lutomirski , David Howells , "Theodore Y. Ts'o" , Linus Torvalds , Linux FS Devel , Linux API Subject: Re: [git pull] new mount API Message-ID: <20180824195112.GN6515@ZenIV.linux.org.uk> References: <20180824031311.GM6515@ZenIV.linux.org.uk> <20180824060532.GG16817@thunk.org> <362.1535103931@warthog.procyon.org.uk> <015EF93F-1BC8-4000-ABBC-233F73D09384@amacapital.net> <15252.1535130642@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Aug 24, 2018 at 09:25:58PM +0200, Miklos Szeredi wrote: > On Fri, Aug 24, 2018 at 7:43 PM, Andy Lutomirski wrote: > > On Fri, Aug 24, 2018 at 10:10 AM, David Howells wrote: > >> Andy Lutomirski 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?