linux-kernel - Re: odd objtool 'unreachable instruction' warning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aQWxNvi7FOkHt-bV@gmail.com>
Date: Sat, 1 Nov 2025 08:05:26 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: odd objtool 'unreachable instruction' warning

* Linus Torvalds <torvalds@...ux-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