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: <e62d4c3a-b89b-2380-7b39-66733b389145@gmail.com>
 <CAEJqkggwbNP3Q+7AWr4i64CvAdCp15jVLOtUsnMo6rLk3ExTkA@mail.gmail.com> <CAHk-=wjd2VJDM+RXwg30MpW45F5EHZtLErzxQzYxi4+Dnm3sjw@mail.gmail.com>
In-Reply-To: <CAHk-=wjd2VJDM+RXwg30MpW45F5EHZtLErzxQzYxi4+Dnm3sjw@mail.gmail.com>
From:   Christian Brauner <christian.brauner@canonical.com>
Date:   Sat, 22 Dec 2018 23:48:54 +0100
Message-ID: <CAPP7u0Vo6gB86S-hZcOW9Rmki8oKHd=Lyx3x-N9gjPC4JP_YxQ@mail.gmail.com>
Subject: Re: [BREAKAGE] Since 4.18, kernel sets SB_I_NODEV implicitly on
 userns mounts, breaking systemd-nspawn
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     nix.or.die@gmail.com, "Eric W. Biederman" <ebiederm@xmission.com>,
        ellierevves@gmail.com,
        Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Seth Forshee <seth.forshee@canonical.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Dec 22, 2018 at 11:20 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Eric, this is entirely unacceptable.

i would like to point out that I send a revert for this in *July*
before any kernel with this change
was released for the exact same reason. But I was ignored and no one
came to argumentative aid:
- https://lists.linuxfoundation.org/pipermail/containers/2018-July/039182.html
- https://lists.linuxfoundation.org/pipermail/containers/2018-July/039183.html

To be fair, no one apart from me was pointing out that it actually
breaks people including systemd folks
even though I was bringing it up with them. I even tried to fix all of
userspace after this got NACKED
( https://github.com/systemd/systemd/pull/9483 ).

Christian

>
> On Sat, Dec 22, 2018 at 12:58 PM Gabriel C <nix.or.die@gmail.com> wrote:
> >
> > Added some people to CC that might want to see this..
>
> Thanks.
>
> > > Here's an email that was sent to lkml about the subject:
> > >
> > > https://lkml.org/lkml/2018/7/5/742
> > >
> > > I link also this, quoting the last of it:
> > >
> > > https://lkml.org/lkml/2018/7/5/701
> > >
> > > It has never been the case that mknod on a device node will guarantee
> > > that you even can open the device node.  The applications that regress
> > > are broken.  It doesn't mean we shouldn't be bug compatible, but we darn
> > > well should document very clearly the bugs we are being bug compatible with.
>
> Yeah, this is complete garbage.
>
> We have very clear rules in the kernel: if some change breaks existing
> setups, it is ABSOLUTELY NEVER the application that is broken.
>
> It is the kernel.
>
> There is absolutely zero gray areas here. Eric, your behavior is
> entirely out of line, and now we apparently have a regression that
> goes back to June that I was not told about because of your incorrect
> stance.
>
> Eric, I want to make this 1000% clear: there are no user space bugs.
> If it used to work, then user space was clearly doing the right thing.
> The fact that you tried to several times claim it was buggy user space
> is a serious breach of trust. You KNOW this is the case.
>
> Seriously. There are no excuses.
>
> That commit is now reverted in my tree, and furthermore I will not
> take any pull requests from you until you have made it clear that you
> comprehend this very fundamental issue.
>
> Why did it take so long for this issue to be elevated to me?
>
>                    Linus