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> <CAPP7u0Vo6gB86S-hZcOW9Rmki8oKHd=Lyx3x-N9gjPC4JP_YxQ@mail.gmail.com>
In-Reply-To: <CAPP7u0Vo6gB86S-hZcOW9Rmki8oKHd=Lyx3x-N9gjPC4JP_YxQ@mail.gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat, 22 Dec 2018 15:01:55 -0800
Message-ID: <CAHk-=wg-6jYZ=bJWdyBR=n8QOfwHTZZdzSUUPgFW+NGCV-pe2g@mail.gmail.com>
Subject: Re: [BREAKAGE] Since 4.18, kernel sets SB_I_NODEV implicitly on
 userns mounts, breaking systemd-nspawn
To:     christian.brauner@canonical.com
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@canonical.com
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Dec 22, 2018 at 2:49 PM Christian Brauner
<christian.brauner@canonical.com> wrote:
>
> 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

Seriously, the "we don't break user space" is the #1 rule in the
kernel, and people should _know_ it's the #1 rule.

If somebody ignores that rule, it needs to be escalated to me.
Immediately. Because I need to know.

I need to know so that I can override the bogus NAK, and so that we
can fix the breakage ASAP. The absolute last thing we need is some
other user space then starting to rely on the new behavior, which just
compounds the problem and makes it a *much* bigger problem.

But I also need to know so that I can then make sure I know not to
trust the person who broke rule #1.

This is not some odd corner case for the kernel. This is literally the
rule we have lived with for *decades*.

So please escalate to me whenever you feel a kernel developer doesn't
follow the first rule. Because the code that broke things *will* be
reverted (*).

                    Linus

(*) Yes, there are exceptions. We have had situations where some
interface was simply just a huge security issue or had some other
fundamental issue. And we've had cases where the breakage was just so
old that it was no longer fixable. So even rule #1 can sometimes have
things that hold it back. But it is *very* rare. Certainly nothing
like this.