Re: [PATCH] sched: Work around undefined behavior in sched class checking

* Peter Zijlstra:

On Tue, May 04, 2021 at 08:39:45PM -0700, Andi Kleen wrote:

quoted

From: Andi Kleen <redacted>

The scheduler initialization code checks that the scheduling
classes are consecutive in memory by comparing the end
addresses with the next address.

Technically in ISO C comparing symbol addresseses outside different objects
is undefined. With LTO gcc 10 tries to exploits this and creates an
unconditional BUG_ON in the scheduler initialization, resulting
in a boot hang.

Use RELOC_HIDE to make this work. This hides the symbols from gcc,
so the optimizer won't make these assumption. I also split
the BUG_ONs in multiple.

Urgh, that insanity again :/ Can't we pretty please get a GCC flag to
disable that?

Context:

  <https://lore.kernel.org/lkml/20210505033945.1282851-1-ak@linux.intel.com/>

Obviously, GCC doesn't do this in general.  Would you please provide a
minimal test case?

Thanks,
Florian

On Wed, May 05, 2021 at 10:47:07AM +0200, Florian Weimer wrote:

* Peter Zijlstra:

quoted

On Tue, May 04, 2021 at 08:39:45PM -0700, Andi Kleen wrote:

quoted

From: Andi Kleen <redacted>

The scheduler initialization code checks that the scheduling
classes are consecutive in memory by comparing the end
addresses with the next address.

Technically in ISO C comparing symbol addresseses outside different objects
is undefined. With LTO gcc 10 tries to exploits this and creates an
unconditional BUG_ON in the scheduler initialization, resulting
in a boot hang.

Use RELOC_HIDE to make this work. This hides the symbols from gcc,
so the optimizer won't make these assumption. I also split
the BUG_ONs in multiple.

Urgh, that insanity again :/ Can't we pretty please get a GCC flag to
disable that?

Context:

  <https://lore.kernel.org/lkml/20210505033945.1282851-1-ak@linux.intel.com/>

Obviously, GCC doesn't do this in general.  Would you please provide a
minimal test case?

Andi has this GCC-LTO patch-set that triggers this, but the thing I'd
like fixed is the UB mentioned above. Not this particular instance.

And, we've had the problem before, see all the RELOC_HIDE crud. Having
this pointer arith outside object be UB is just really annoying. And in
the spirit of UB bad, can we please get a flag to remove the UB and have
it do the obvious, just do the arithmetic and don't do daft things.

Pretty please.

Context:

  <https://lore.kernel.org/lkml/20210505033945.1282851-1-ak@linux.intel.com/>

Obviously, GCC doesn't do this in general. 

We've seen it in other cases before, that's why RELOC_HIDE exists.
A classic case was __pa_symbol()

That dates back nearly two decades at this point.

 Would you please provide a
minimal test case?

You can only reproduce it with a LTO build because it needs knowledge
between different translation units for this specific case.

But gcc will totally do the optimization even without LTO if it can
prove the same inside a single TU.

If you want to reproduce it you can use my tree here
git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc lto-5.12-3
and revert the fix. The kernel will not boot.

-Andi

On 5/5/2021 9:41 AM, Nick Desaulniers wrote:

On Wed, May 5, 2021 at 7:39 AM Andi Kleen [off-list ref] wrote:

quoted

quoted

  Would you please provide a
minimal test case?

You can only reproduce it with a LTO build because it needs knowledge
between different translation units for this specific case.

But gcc will totally do the optimization even without LTO if it can
prove the same inside a single TU.

It would be helpful to isolate a test case that doesn't rely on LTO,
if possible.

Like I wrote earlier we used to see it all the time in __pa_symbol 
before it used RELOC_HIDE. I bet if you make RELOC_HIDE a nop you'll see 
multiple instances.

But not sure why you want a test case?

-Andi

On Wed, May 5, 2021 at 7:39 AM Andi Kleen [off-list ref] wrote:

quoted

 Would you please provide a
minimal test case?

You can only reproduce it with a LTO build because it needs knowledge
between different translation units for this specific case.

But gcc will totally do the optimization even without LTO if it can
prove the same inside a single TU.

It would be helpful to isolate a test case that doesn't rely on LTO,
if possible.
-- 
Thanks,
~Nick Desaulniers

quoted

But not sure why you want a test case?

In general,
when making a feature request to a compiler vendor, having a
digestible snippet of code that demonstrates the problem goes a long
way, much further than "clone this branch of my fork of this project
and do a build and something goes wrong somewhere."  We're too busy to
do that, please take the time to isolate it before making such
requests.

Ah you misunderstood. I'm not making any feature requests.

-Andi

On Wed, May 5, 2021 at 9:49 AM Andi Kleen [off-list ref] wrote:

On 5/5/2021 9:41 AM, Nick Desaulniers wrote:

quoted

On Wed, May 5, 2021 at 7:39 AM Andi Kleen [off-list ref] wrote:

quoted

quoted

  Would you please provide a
minimal test case?

You can only reproduce it with a LTO build because it needs knowledge
between different translation units for this specific case.

But gcc will totally do the optimization even without LTO if it can
prove the same inside a single TU.

It would be helpful to isolate a test case that doesn't rely on LTO,
if possible.

Like I wrote earlier we used to see it all the time in __pa_symbol
before it used RELOC_HIDE. I bet if you make RELOC_HIDE a nop you'll see
multiple instances.

But not sure why you want a test case?

In general,
when making a feature request to a compiler vendor, having a
digestible snippet of code that demonstrates the problem goes a long
way, much further than "clone this branch of my fork of this project
and do a build and something goes wrong somewhere."  We're too busy to
do that, please take the time to isolate it before making such
requests.

-- 
Thanks,
~Nick Desaulniers