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] [day] [month] [year] [list]

Message-ID: <CAHk-=wj-DzB2nbzxHDdHOboFTJynMJSGcB7+g-e9jWrCbBynqA@mail.gmail.com>
Date: Sat, 1 Nov 2025 09:59:43 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...nel.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

On Sat, 1 Nov 2025 at 00:05, Ingo Molnar <mingo@...nel.org> wrote:
>
> 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").

So I think I mentioned in one other email (maybe another thread) that
I did at one point have a slightly bigger patch that then had more
#ifdef's etc to make it configurable and thus upstreamable.

The problem was that it just made the source uglier. The patch simply
looked pretty hacky, and it's not like it really improves anything for
anybody sane: the actual code at runtime ends up being identical.

(It might improve things for really old machines that don't support
SMAP at all, in that they'd avoid the nop instructions, but I don't
feel that is something worth optimizing for).

Now, if there are enough people that actually look at the assembler
code to make this worthwhile, that would be one thing, but I suspect
there's a handful of odd people who - like me - are then happy to have
local crud that doesn't affect anybody else.

But hey - if you think this would be good upstream, and you (and by
"you" I mean "the x86 maintainers" in general) don't mind having a
slightly more complicated ugly header file, I obviously will not
complain at all.

(I also at one point was hoping there was some way to make the
<asm/alternative.h> code itself have a "assume these flags are
set/clear" model, but that looks unworkable: you'd need a more capable
preprocessor than the regular stupid C preprocessor - something that
could do conditionals inside the macros).

               Linus