public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: odd objtool 'unreachable instruction' warning
Date: Sat, 1 Nov 2025 08:05:26 +0100	[thread overview]
Message-ID: <aQWxNvi7FOkHt-bV@gmail.com> (raw)
In-Reply-To: <CAHk-=wi6goUT36sR8GE47_P-aVrd5g38=VTRHpktWARbyE-0ow@mail.gmail.com>


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

> That is a local hack that just removes the alternative noise for the 
> common ops, so that I actually see the fences and clac/stac 
> instructions as such, instead of seeing them as nops in the object 
> file or as horrible noise in the assembler output.
> 
> So that patch is not something I'd ever commit in general, but it's
> really useful for checking code generation [...]

> Subject: [PATCH] Avoid alternative assembler noise for common ops
> 
> Just hardcode the ones I have for SMP and LFENCE
> ---
>  arch/x86/include/asm/alternative.h |  7 +------
>  arch/x86/include/asm/barrier.h     |  2 +-
>  arch/x86/include/asm/smap.h        | 18 ++++++------------
>  arch/x86/lib/getuser.S             |  2 +-
>  4 files changed, 9 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h
> index 15bc07a5ebb3..281c823a869e 100644
> --- a/arch/x86/include/asm/alternative.h
> +++ b/arch/x86/include/asm/alternative.h
> @@ -42,12 +42,7 @@
>   */
>  
>  #ifdef CONFIG_SMP
> -#define LOCK_PREFIX_HERE \
> -		".pushsection .smp_locks,\"a\"\n"	\
> -		".balign 4\n"				\
> -		".long 671f - .\n" /* offset */		\
> -		".popsection\n"				\
> -		"671:"
> +#define LOCK_PREFIX_HERE

>  
>  #define LOCK_PREFIX LOCK_PREFIX_HERE "\n\tlock "
>  
> diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
> index db70832232d4..2b911c88467b 100644
> --- a/arch/x86/include/asm/barrier.h
> +++ b/arch/x86/include/asm/barrier.h
> @@ -45,7 +45,7 @@
>  	__mask; })
>  
>  /* Prevent speculative execution past this barrier. */
> -#define barrier_nospec() alternative("", "lfence", X86_FEATURE_LFENCE_RDTSC)
> +#define barrier_nospec() asm volatile("lfence":::"memory")

So we could actually integrate much of this and avoid all the 
alternatives noise by keying it off CONFIG_X86_NATIVE_CPU and passing 
in two new config flags whether /proc/cpuinfo in the build environment 
has X86_FEATURE_LFENCE_RDTSC and X86_FEATURE_SMAP ("smap").

CONFIG_X86_NATIVE_CPU is not supposed to boot/work on any other CPU 
than the host CPU, so CPU-variant runtime patchery is pointless there.

Put differently: we could make alternative() use build-provided CPU 
flags if CONFIG_X86_NATIVE_CPU=y - or at least introduce an 
alternative() variant that can be used in the simpler cases.

We could even avoid .smp_locks if the build environment is SMP, or even 
just hardcode the LOCK prefix on CONFIG_X86_NATIVE_CPU, there's no 
modern UP processor in existence that we support and care about, and 
patching out the prefix should be of dubious value anyway on anything 
supported. LOCK used to have horrible overhead on some ancient CPUs but 
that's it - it should be ignored on any x86 CPU built in the last 20 
years?

Ie. I think we could integrate 100% of the functionality of your 
disassembly readability hack-patch. :-)

Thanks,

	Ingo

  parent reply	other threads:[~2025-11-01  7:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-28 19:29 odd objtool 'unreachable instruction' warning Linus Torvalds
2025-10-29  0:21 ` Josh Poimboeuf
2025-10-29  0:59   ` Linus Torvalds
2025-10-29  1:50     ` Josh Poimboeuf
2025-10-29 16:17       ` Linus Torvalds
2025-10-30  9:51         ` Alexandre Chartre
2025-11-05 19:51         ` David Sterba
2025-11-07  0:05           ` Linus Torvalds
2025-10-29  9:56 ` David Laight
2025-10-29 10:05   ` Peter Zijlstra
2025-10-29 13:00     ` David Laight
2025-10-29 14:05   ` Peter Zijlstra
2025-11-01  7:05 ` Ingo Molnar [this message]
2025-11-01 16:59   ` Linus Torvalds

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=aQWxNvi7FOkHt-bV@gmail.com \
    --to=mingo@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox