Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Sender: Ingo Molnar <mingo.kernel.org@gmail.com>
Date:   Tue, 3 Oct 2023 21:43:51 +0200
From:   Ingo Molnar <mingo@kernel.org>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Uros Bizjak <ubizjak@gmail.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org, Andy Lutomirski <luto@kernel.org>,
        Nadav Amit <namit@vmware.com>, Brian Gerst <brgerst@gmail.com>,
        Denys Vlasenko <dvlasenk@redhat.com>,
        "H . Peter Anvin" <hpa@zytor.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Borislav Petkov <bp@alien8.de>,
        Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [RFC PATCH 0/4] x86/percpu: Use segment qualifiers
Message-ID: <ZRxu9+ZJqjY/u8ku@gmail.com>
References: <20231001131620.112484-1-ubizjak@gmail.com>
 <CAHk-=wg6P8pPg-x4BPUQj-wE0xC7HkGzFk89ftuji8MVo+RRxw@mail.gmail.com>
 <CAFULd4Y+HXuditB51Q0LznqiBsvxJr3BjEYvx4_224XmqrycCw@mail.gmail.com>
 <CAHk-=wh+cfn58XxMLnG6dH+Eb9-2dYfABXJF2FtSZ+vfqVvWzA@mail.gmail.com>
 <CAFULd4atO8uy_5PbjV8vw-yk0tv_=4kh_JwJ+6Xq-2myStCnmw@mail.gmail.com>
 <CAFULd4YsPnCfw-NV_0ck1_za=WPc-FxYKV1bb99UcAwMJ=34YA@mail.gmail.com>
 <ZRrECdIoKCXALl39@gmail.com>
 <CAFULd4bBzAWoY7MDQN+YV5tpw7vDitFNMuSVt53KGofdZRvTpg@mail.gmail.com>
 <ZRwZOtANkcwtL+5B@gmail.com>
 <CAHk-=wi2d159z-KgZTAk52GZHB8=B-HZ-fQ_890fN7CL6Yt89g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHk-=wi2d159z-KgZTAk52GZHB8=B-HZ-fQ_890fN7CL6Yt89g@mail.gmail.com>
Precedence: bulk


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, 3 Oct 2023 at 06:38, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > So I don't think it's a good idea to restrict it to the devel GCC version
> > only, the cross-section of devel-GCC and devel-kernel reduces testing
> > coverage to near-zero in practice ...
> 
> In fact, while the clang failure was arguably worse from a code
> generation standpoint (as in "it didn't generate any code AT ALL"), it
> was actually better from a kernel standpoint: I'd *much* rather have a
> compile-time failure than bad code generation when it's a particular
> issue that we can avoid by just not doing it.
> 
> IOW, *if* this is the only actual issue with named address spaces,
> then I'd much rather have a compiler that says "don't do that" over a
> compiler that silently generates absolutely horrendous code.
> 
> That is not unlike my "I'd rather get a link time error from trying to
> do a 64-by-64 divide on x86-32, than have the compiler actually
> generate that horrendously expensive operation". There's a reason we
> have "do_div64()" to do 64-by-32 divides, because that's usually what
> you actually want.
> 
> We should not be doing big structure copies from or to the percpu
> area, so clang then failing with an admittedly horrendous error
> message is not a bad thing.
> 
> And again - my worry really isn't this "copy a percpu structure"
> issue. It's literally just that I feel this doesn't have a lot of
> coverage.

I share all those concerns.

So we could do this: we let it live in -tip for a cycle, in a separate
branch, and observe what happens - it gets picked up by -next on
a daily basis and most x86 developers test it. It won't be merged by other
branches in -tip, it won't be pulled by others or relied on. If it
conflicts with other bits we rebase it cleanly, no questions asked.

While -next test coverage is still limited in many ways, it's also
certainly not zero.

If it's problem-free for a cycle I'll offer it up to you as an RFC pull,
summarizing our experience with it. (Should it ever get to that point.)

That's the best I think we can do - and worst-case we'll turn it off
again and go curse flaky compiler features. Will be easy to turn off
if it's compiler version triggered anyway.

Thanks,

	Ingo