From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
x86@kernel.org, llvm@lists.linux.dev,
linux-sparse@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel test robot <lkp@intel.com>,
Nathan Chancellor <nathan@kernel.org>
Subject: Re: [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER__
Date: Tue, 18 Jan 2022 16:03:27 -0800 [thread overview]
Message-ID: <20220119000327.oapghqad4lebnsra@treble> (raw)
In-Reply-To: <YedOLva0zos3A1JE@zn.tnic>
On Wed, Jan 19, 2022 at 12:33:02AM +0100, Borislav Petkov wrote:
> On Tue, Jan 18, 2022 at 03:01:20PM -0800, Josh Poimboeuf wrote:
> > 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.
>
> Could that be the same thing:
>
> net/xfrm/xfrm_output.o: warning: objtool: xfrm_output_resume()+0x2e0: unreachable instruction
>
> I see two WARN_ONs in asm output there too...
If one of the '__bug_table' asm snippets isn't immediately followed by
the .L[un]reachable asm, then yeah, it's the same issue.
For example it's supposed to look something like this:
# 472 "net/xfrm/xfrm_output.c" 1
1: .byte 0x0f, 0x0b
.pushsection __bug_table,"aw"
2: .long 1b - 2b # bug_entry::bug_addr
.long .LC4 - 2b # bug_entry::file #
.word 472 # bug_entry::line #
.word 2307 # bug_entry::flags #
.org 2b+12 #
.popsection
# 0 "" 2
# 472 "net/xfrm/xfrm_output.c" 1
.Lreachable1666:
.pushsection .discard.reachable
.long .Lreachable1666 - .
.popsection
NOT just this:
# 472 "net/xfrm/xfrm_output.c" 1
1: .byte 0x0f, 0x0b
.pushsection __bug_table,"aw"
2: .long 1b - 2b # bug_entry::bug_addr
.long .LC4 - 2b # bug_entry::file #
.word 472 # bug_entry::line #
.word 2307 # bug_entry::flags #
.org 2b+12 #
.popsection
# some other code here...
There's a bunch of those throughout the code base. The current
annotate_[un]reachable() implementations are carefully written to avoid
that happening.
--
Josh
next prev parent reply other threads:[~2022-01-19 0:03 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 [this message]
2022-01-19 10:01 ` Borislav Petkov
2022-01-24 23:26 ` Nick Desaulniers
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220119000327.oapghqad4lebnsra@treble \
--to=jpoimboe@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=gor@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=luc.vanoostenryck@gmail.com \
--cc=mingo@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.