Re: [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER__

Re: [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER__

[Nick Desaulniers]

(sorry for the delay responding, took a week off last week; spent a
lot of it thinking about this case though)

On Tue, Jan 18, 2022 at 3:01 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> On Tue, Jan 18, 2022 at 11:22:59AM -0800, Josh Poimboeuf wrote:
> > On Sun, Jan 16, 2022 at 02:32:59PM +0100, Borislav Petkov wrote:
> > > so I like the local label and how it is more readable this way.
> > >
> > > So, provided the memory clobber works (I wonder here if Josh has some
> > > concrete failing cases which could be tested with your version) and
> > > after the nitpicks have been addressed
> > >
> > > Acked-by: Borislav Petkov <bp@suse.de>
> >
> > I think Nick was already able to recreate the original issue.  I'll run
> > it through some more testing.
> >
> > I wanted to make this change years ago, but couldn't because of legacy
> > toolchains.  Here's hoping this is the final solution for those @#$%^
> > macros.
> >
> > Boris, thanks for looping Nick in, I should have done so to begin with.

No worries, we'll get all this sorted.  There's also
linux-toolchains@vger.kernel.org that can help with spooky toolchain
behavior.

I suspect this is what's causing a flood of objtool warnings when we
specify different instruction schedules via -march= (such as via
CONFIG_MATOM), which are hiding some of the actual codegen bugs
objtool has found in LLVM that we still need to fix.

I was looking at the HAVE_ARCH_BUG implementation in
arch/x86/include/asm/bug.h 2 weeks ago, and got the sinking feeling
that we'll probably need labels in C code, then asm goto to ensure
that control flow doesn't get folded in an unexpected way and which
I'd imagine might help avoid the costs of a full compiler barrier
(i.e. reloading all pointed-to values across it).

I'll follow up more with Josh on IRC on some ideas for different
approaches.  Having 0day bot test Josh's branches is very much
appreciated.

> Apparently this patch isn't going to work after all :-(
>
>   https://lkml.kernel.org/r/202201190632.lhlaiCBk-lkp@intel.com

I noticed in that report and
https://lore.kernel.org/lkml/202201190702.XNSXrMTK-lkp@intel.com/
that gcc-9 was used.  I wonder if %= has been fixed in gcc-10+? Have
there been other reports with gcc-10+ for my patch?

Boris' case of xfrm_output_resume is yet a third case; Boris, what
version of gcc did you spot that with?

If this is fixed in gcc-10, then we can probably add a comment with a
FIXME link to the issue or commit to replace __COUNTER__ with %= one
day.  If not, then we can probably come up with a reduced test case
for the GCC devs to take a look at, then add the FIXME comment to
kernel sources.

I'm more confident that we can remove the `volatile` keyword (I was
thinking about adding a new diagnostic to clang to warn that volatile
is redundate+implied for asm goto or inline asm that doesn't have
outputs) though that's not the problem here and will probably generate
some kernel wide cleanup before we could enable such a flag.  Perhaps
there are known compiler versions that still require the keyword for
those cases for some reason.

>
> With the two WARN_ONs in media_request_object_complete(), GCC apparently
> considers the two reachable() asm statements as duplicates, and it
> removes the second one.

On Fri, Jan 14, 2022 at 1:58 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> Perhaps it is worth mentioning in the next paragraph that this does not
> contradict GCC's own documentation that you link to below, which
> mentions that asm volatile statements can be reordered.
>
> "Note that the compiler can move even volatile asm instructions relative
> to other code, including across jump instructions."

On Sun, Jan 16, 2022 at 5:33 AM Borislav Petkov <bp@alien8.de> wrote:
>
> Yah, Nathan's note about talking about gcc reordering volatile inline
> asms might make sense here as, apparently, that could have failed on gcc
> too but it didn't for whatever reason and the most important thing is
> that the memory clobber will prevent such reordering.

Very much YES to both points.  Will include those in the commit
message for whatever we come up with for the final solution.
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER__

[Nick Desaulniers]

On Mon, Jan 24, 2022 at 3:26 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Tue, Jan 18, 2022 at 3:01 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >
> > Apparently this patch isn't going to work after all :-(
> >
> >   https://lkml.kernel.org/r/202201190632.lhlaiCBk-lkp@intel.com
>
> I noticed in that report and
> https://lore.kernel.org/lkml/202201190702.XNSXrMTK-lkp@intel.com/
> that gcc-9 was used.  I wonder if %= has been fixed in gcc-10+? Have
> there been other reports with gcc-10+ for my patch?
>
> Boris' case of xfrm_output_resume is yet a third case; Boris, what
> version of gcc did you spot that with?
>
> If this is fixed in gcc-10, then we can probably add a comment with a
> FIXME link to the issue or commit to replace __COUNTER__ with %= one
> day.  If not, then we can probably come up with a reduced test case
> for the GCC devs to take a look at, then add the FIXME comment to
> kernel sources.


$ wget https://download.01.org/0day-ci/archive/20220119/202201190702.XNSXrMTK-lkp@intel.com/config
-O .config
$ make -j72 -s olddefconfig drivers/net/wireless/mac80211_hwsim.o
drivers/net/wireless/mac80211_hwsim.o: warning: objtool:
mac80211_hwsim_tx()+0x9aa: unreachable instruction
$ gcc --version
gcc (Debian 11.2.0-12) 11.2.0

:(

Let me see if I can come up with a reduced test case that I will
report upstream to https://gcc.gnu.org/bugzilla/.
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER__

[Borislav Petkov]

On Mon, Jan 24, 2022 at 03:38:38PM -0800, Nick Desaulniers wrote:
> $ wget https://download.01.org/0day-ci/archive/20220119/202201190702.XNSXrMTK-lkp@intel.com/config
> -O .config
> $ make -j72 -s olddefconfig drivers/net/wireless/mac80211_hwsim.o
> drivers/net/wireless/mac80211_hwsim.o: warning: objtool:
> mac80211_hwsim_tx()+0x9aa: unreachable instruction
> $ gcc --version
> gcc (Debian 11.2.0-12) 11.2.0

Yap, I got mine with:

gcc (Debian 10.2.1-6) 10.2.1 20210110

but since you hit it with gcc11, I don't see why I won't hit it with
gcc10.

> :(

You said it.
 
> Let me see if I can come up with a reduced test case that I will
> report upstream to https://gcc.gnu.org/bugzilla/.

Sounds good.

Please send the bug # once you have that so that I can add myself to Cc.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER__

[Segher Boessenkool]

Hi!

On Mon, Jan 24, 2022 at 03:26:36PM -0800, Nick Desaulniers wrote:
> I noticed in that report and
> https://lore.kernel.org/lkml/202201190702.XNSXrMTK-lkp@intel.com/
> that gcc-9 was used.  I wonder if %= has been fixed in gcc-10+? Have
> there been other reports with gcc-10+ for my patch?

None of the %= code (which is trivial) has been changed since 1992.

> If this is fixed in gcc-10, then we can probably add a comment with a
> FIXME link to the issue or commit to replace __COUNTER__ with %= one
> day.  If not, then we can probably come up with a reduced test case
> for the GCC devs to take a look at, then add the FIXME comment to
> kernel sources.

Please open a PR?

> I'm more confident that we can remove the `volatile` keyword (I was
> thinking about adding a new diagnostic to clang to warn that volatile
> is redundate+implied for asm goto or inline asm that doesn't have
> outputs) though that's not the problem here and will probably generate
> some kernel wide cleanup before we could enable such a flag.

Its main value is that it would discourage users from thinking volatile
is magic.  Seriously worth some pain!

> Perhaps
> there are known compiler versions that still require the keyword for
> those cases for some reason.

It was removed from compiler-gcc.h in 3347acc6fcd4 (which changed the
minimum required GCC version to GCC 5).


Segher

Re: [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER__

[Nick Desaulniers]

On Tue, Jan 25, 2022 at 3:34 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> Hi!
>
> On Mon, Jan 24, 2022 at 03:26:36PM -0800, Nick Desaulniers wrote:
>
> > If this is fixed in gcc-10, then we can probably add a comment with a
> > FIXME link to the issue or commit to replace __COUNTER__ with %= one
> > day.  If not, then we can probably come up with a reduced test case
> > for the GCC devs to take a look at, then add the FIXME comment to
> > kernel sources.
>
> Please open a PR?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104236

> > I'm more confident that we can remove the `volatile` keyword (I was
> > thinking about adding a new diagnostic to clang to warn that volatile
> > is redundate+implied for asm goto or inline asm that doesn't have
> > outputs) though that's not the problem here and will probably generate
> > some kernel wide cleanup before we could enable such a flag.
>
> Its main value is that it would discourage users from thinking volatile
> is magic.  Seriously worth some pain!

Yeah, SGTM.

>
> > Perhaps
> > there are known compiler versions that still require the keyword for
> > those cases for some reason.
>
> It was removed from compiler-gcc.h in 3347acc6fcd4 (which changed the
> minimum required GCC version to GCC 5).

```
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index e512f5505dad..b8fe0c23cfff 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -80,11 +80,25 @@ void ftrace_likely_update(struct
ftrace_likely_data *f, int val,

 /* Optimization barrier */
 #ifndef barrier
-# define barrier() __memory_barrier()
+/* The "volatile" is due to gcc bugs */
+# define barrier() __asm__ __volatile__("": : :"memory")
```

I definitely wish there was a comment with a link to what "gcc bugs"
they were referring to; otherwise who knows if it's been fixed...if
they have been...
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER__

[Nick Desaulniers]

On Tue, Jan 25, 2022 at 4:59 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Tue, Jan 25, 2022 at 3:34 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > Hi!
> >
> > On Mon, Jan 24, 2022 at 03:26:36PM -0800, Nick Desaulniers wrote:
> >
> > > If this is fixed in gcc-10, then we can probably add a comment with a
> > > FIXME link to the issue or commit to replace __COUNTER__ with %= one
> > > day.  If not, then we can probably come up with a reduced test case
> > > for the GCC devs to take a look at, then add the FIXME comment to
> > > kernel sources.
> >
> > Please open a PR?
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104236

Andrew clarified (thanks Andrew!) that %= can't be used as I imagined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104236#c4
and that I think was alluded to in
commit 3d1e236022cc ("objtool: Prevent GCC from merging annotate_unreachable()")
which is fine, so I'll just need to keep usage of __COUNTER__. I'll
try out a revised approach for this patch tomorrow.
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER__

[Segher Boessenkool]

Hi!

On Tue, Jan 25, 2022 at 06:12:20PM -0800, Nick Desaulniers wrote:
> Andrew clarified (thanks Andrew!) that %= can't be used as I imagined
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104236#c4
> and that I think was alluded to in
> commit 3d1e236022cc ("objtool: Prevent GCC from merging annotate_unreachable()")
> which is fine, so I'll just need to keep usage of __COUNTER__.

Aha.  Yes, %= *outputs* a unique number.  Before the assembler output
is written %= is just a string (like any other piece of output
template).  The output template is used for three things:

1) Inline assembler statements with different output templates are not
considered identical;
2) Newlines and assembler statement separators (semicolons for most
assembler dialects) are used to estimate the size of the machine code
generated.  This is a pessimistic estimate, but within reason: for
example you can write a million byte output with just a few characters
of input, if you want to sabotage yourself;
3) The output template is used at output time.

The mentioned commit's message says "unfortunately older versions of GCC
don't support it" which is mistaken.

If you want two identical inline asm statements to not be considered
identical by the compiler, you have to make them not identical.  Like by
using __COUNTER__ for example, yes :-)


Segher

Re: [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER__

[Nick Desaulniers]

On Tue, Jan 25, 2022 at 3:34 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> Hi!
>
> On Mon, Jan 24, 2022 at 03:26:36PM -0800, Nick Desaulniers wrote:
> > I'm more confident that we can remove the `volatile` keyword (I was
> > thinking about adding a new diagnostic to clang to warn that volatile
> > is redundate+implied for asm goto or inline asm that doesn't have
> > outputs) though that's not the problem here and will probably generate
> > some kernel wide cleanup before we could enable such a flag.
>
> Its main value is that it would discourage users from thinking volatile
> is magic.  Seriously worth some pain!

https://reviews.llvm.org/D118297
PTAL
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER__

[Segher Boessenkool]

On Mon, Jan 31, 2022 at 12:45:20PM -0800, Nick Desaulniers wrote:
> On Tue, Jan 25, 2022 at 3:34 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > Hi!
> >
> > On Mon, Jan 24, 2022 at 03:26:36PM -0800, Nick Desaulniers wrote:
> > > I'm more confident that we can remove the `volatile` keyword (I was
> > > thinking about adding a new diagnostic to clang to warn that volatile
> > > is redundate+implied for asm goto or inline asm that doesn't have
> > > outputs) though that's not the problem here and will probably generate
> > > some kernel wide cleanup before we could enable such a flag.
> >
> > Its main value is that it would discourage users from thinking volatile
> > is magic.  Seriously worth some pain!
> 
> https://reviews.llvm.org/D118297
> PTAL

""
  Really the volatile asm-qualifier exists only to signal that an asm
  statement should not be DCE'd (when it has outputs but they are unused),
  CSE'd, or LICM'd. It is not a general compiler barrier.

It means that the asm has a side effect (one unknown to the compiler),
so it must be executed in the real machine just where it would be in the
abstract machine.  It *can* be CSEd, it *can* be DCEd, it can even be
optimised by LICM in certain cases: but it has to be executed as often
(and in the same order etc.) in the resulting machine code as it would
be if you single-stepped through the source code by hand.

Those are fine examples if you add "in most cases" (and that they are
just examples, it's not an exhaustive list).

Thanks,


Segher