All of
 help / color / mirror / Atom feed
From: Nick Desaulniers <>
To: Josh Poimboeuf <>
Cc: Borislav Petkov <>, Vasily Gorbik <>,
	 Linus Torvalds <>,
	Ingo Molnar <>,
	 Dave Hansen <>,
	Thomas Gleixner <>,
	 Peter Zijlstra <>,
	Luc Van Oostenryck <>,,,,,
	kernel test robot <>,
	 Nathan Chancellor <>,
Subject: Re: [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER__
Date: Mon, 24 Jan 2022 15:26:36 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20220118230120.pivvson7qekfiqic@treble>

(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 <> 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 <>
> >
> > 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 that can help with spooky toolchain

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

> Apparently this patch isn't going to work after all :-(

I noticed in that report and
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 <> 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 <> 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.
~Nick Desaulniers

  parent reply	other threads:[~2022-01-24 23:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-14  1:05 [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER__ Nick Desaulniers
2022-01-14 21:58 ` Nathan Chancellor
2022-01-16 13:32 ` Borislav Petkov
2022-01-18 19:22   ` Josh Poimboeuf
2022-01-18 23:01     ` Josh Poimboeuf
2022-01-18 23:33       ` Borislav Petkov
2022-01-19  0:03         ` Josh Poimboeuf
2022-01-19 10:01           ` Borislav Petkov
2022-01-24 23:26       ` Nick Desaulniers [this message]
2022-01-24 23:38         ` Nick Desaulniers
2022-01-25 18:49           ` Borislav Petkov
2022-01-25 23:31         ` Segher Boessenkool
2022-01-26  0:59           ` Nick Desaulniers
2022-01-26  2:12             ` Nick Desaulniers
2022-01-26 11:13               ` Segher Boessenkool
2022-01-31 20:45           ` Nick Desaulniers
2022-01-31 22:13             ` Segher Boessenkool

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.