LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
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>
Subject: Re: [git pull] mount API series
Date: Thu, 1 Nov 2018 11:33:31 -0700	[thread overview]
Message-ID: <CAHk-=whysoVxJU8+TBw=D3xN00HOOqg-9Chc=i0Pt+Ozm3Z0Tg@mail.gmail.com> (raw)
In-Reply-To: <28156.1541092687@warthog.procyon.org.uk>

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

  reply	other threads:[~2018-11-01 18:33 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-31  5:33 Al Viro
2018-10-31 15:38 ` Eric W. Biederman
2018-10-31 16:18   ` Eric W. Biederman
2018-10-31 16:36   ` Al Viro
2018-11-01 16:51     ` Al Viro
2018-11-10 14:19   ` Steven Whitehouse
2018-11-12  2:07     ` Eric W. Biederman
2018-11-12 20:54       ` Al Viro
2018-12-17 23:10         ` Al Viro
2018-12-21 16:25           ` Eric W. Biederman
2018-10-31 16:18 ` Linus Torvalds
2018-11-01 10:53   ` Steven Whitehouse
2018-11-01 15:57     ` Linus Torvalds
2018-11-01 17:18     ` David Howells
2018-11-01 18:33       ` Linus Torvalds [this message]
2018-11-01 22:05         ` Al Viro
2018-11-01 22:07           ` Linus Torvalds
2018-11-01 23:59       ` David Howells
2018-11-02  4:07         ` Al Viro
2018-11-02 19:42           ` Al Viro
2018-11-03  6:14             ` Gao Xiang
2018-11-03  6:30           ` Gao Xiang
2018-10-31 18:39 ` David Howells
2018-10-31 20:49   ` Miklos Szeredi
2018-10-31 18:45 ` [PATCH] vfs: Fix incorrect user_ns assignment in proc and mqueue David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=whysoVxJU8+TBw=D3xN00HOOqg-9Chc=i0Pt+Ozm3Z0Tg@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=alan.christopher.jenkins@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@redhat.com \
    --cc=john.johansen@canonical.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=swhiteho@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --subject='Re: [git pull] mount API series' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).