Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20181031053355.GQ32577@ZenIV.linux.org.uk> <CAHk-=whAE6gVi18=u4sSWe1m2RWPh19YCkKQmW4Kx+NQX1mg8w@mail.gmail.com>
 <af28fc2c-d207-875e-8070-f64ead878b5a@redhat.com> <CAHk-=wjjVRQVZL+QMnb=CyCOY8yzEZ=S1DBCE7=FiiWsQfV_5Q@mail.gmail.com>
 <28156.1541092687@warthog.procyon.org.uk>
In-Reply-To: <28156.1541092687@warthog.procyon.org.uk>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu, 1 Nov 2018 11:33:31 -0700
Message-ID: <CAHk-=whysoVxJU8+TBw=D3xN00HOOqg-9Chc=i0Pt+Ozm3Z0Tg@mail.gmail.com>
Subject: Re: [git pull] mount API series
To:     dhowells@redhat.com
Cc:     swhiteho@redhat.com, john.johansen@canonical.com,
        alan.christopher.jenkins@gmail.com,
        Al Viro <viro@zeniv.linux.org.uk>, ebiederm@redhat.com,
        linux-fsdevel@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Nov 1, 2018 at 10:18 AM David Howells <dhowells@redhat.com> wrote:
>
> No.  What we have upstream now is most definitely *not* atomic.  That said,
> some of the steps of the sequence are atomic in their own right:

It's more that what we have traditionally is atomic wrt user space.
Use space does *one* indivisible operation. There's no way for
user-space to do a half-way mount and say "ok, that's it, I'll just
exit now" (or skip a phase and fool the kernel into handling a
half-way setup issue).

So the new model does require a bit more care in tear-down etc. I'm
not so worried about this, actually, but it *is* different.

Afaik, some of the bugs were exactly in this half-way state bits.

[ And yes, looking back at some the reports I found, it was Alan
Jenkins and mainly the open-tree thing. ]

> Would you be willing to take just the *internal* fs_context changes and leave
> the UAPI for the next window?

Hmm. I had to think about that, but the more I thought about it, the
more I liked it.

Yes. Depending on how that is done, that would make a lot of my
worries go away. *Particularly* if it then allows us to do the
per-filesystem conversion one by one.

So if the patch series can be split up into a prep-phase that doesn't
change any user-visible semantics (including the security side), but
that uses the fs_context internally and allows the filesystems to be
converted to the new world order, than that would make merging the
early work much easier (and then my worry about the later phases would
probably be much less too).

It would be _really_ nice to see that prep-phase be done in a way
where each individual patch very obviously doesn't change semantics.
If it's obvious, then I'm happy to consider that pure prep-work and
willing to merge it after the merge window in order to make the _next_
merge window easier.

Al - can I ask you to look at helping David with something like that?
You tend to be very good at generating those patch-series with
"obviously no changes" for the individual patches, but the end result
ends up being totally different from the starting point (I'm thinking
of all the locking and dentry refcounting series).

              Linus