From: Peter Zijlstra <peterz@infradead.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, Ard Biesheuvel <ardb@kernel.org>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
stable@vger.kernel.org
Subject: Re: [PATCH] x86/boot/compressed: Disable jump tables for clang
Date: Wed, 24 Jun 2026 11:38:48 +0200 [thread overview]
Message-ID: <20260624093848.GA48970@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <ajulLtY29HtgWokg@gmail.com>
On Wed, Jun 24, 2026 at 11:36:46AM +0200, Ingo Molnar wrote:
>
> * Nathan Chancellor <nathan@kernel.org> wrote:
>
> > After a recent upstream LLVM change to start generating jump and lookup
> > tables in switch statements in more instances [1], linking the
> > compressed x86 boot image when CONFIG_KERNEL_ZSTD is enabled fails with:
> >
> > ld.lld: error: Unexpected run-time relocations (.rela) detected!
> >
> > Dumping the relocations in misc.o, which is the only file influenced by
> > CONFIG_KERNEL_ZSTD in the decompressor, shows dynamic relocations to
> > some string constants, which correspond to the string literals in the
> > switch statement in handle_zstd_error():
> >
> > Relocation section '.rela.data.rel.ro' at offset 0x277b0 contains 31 entries:
> > Offset Info Type Symbol's Value Symbol's Name + Addend
> > 0000000000000000 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 73a
> > 0000000000000008 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e
> > 0000000000000010 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e
> > 0000000000000018 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e
> > ...
> >
> > This optimization is problematic for the decompressor environment, as it
> > is built as -fPIE without any explicit absolute references (as described
> > at the top of misc.c) while not applying any dynamic relocations, hence
> > the linker assertion. To opt out of this optimization, which is of
> > little value in this special early boot code, disable jump tables in the
> > decompressor when building with clang. This mirrors the other x86
> > startup code in arch/x86/boot/startup.
> >
> > Cc: stable@vger.kernel.org
> > Closes: https://github.com/ClangBuiltLinux/linux/issues/2165
> > Link: https://github.com/llvm/llvm-project/commit/fa02a6ed66b1700c996b49c96c6bc0eb014c9518 [1]
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> > arch/x86/boot/compressed/Makefile | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
> > index 07e0e64b9a98..1c0d29e3eeba 100644
> > --- a/arch/x86/boot/compressed/Makefile
> > +++ b/arch/x86/boot/compressed/Makefile
> > @@ -31,6 +31,7 @@ KBUILD_CFLAGS += -Wundef
> > KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING
> > cflags-$(CONFIG_X86_32) := -march=i386
> > cflags-$(CONFIG_X86_64) := -mcmodel=small -mno-red-zone
> > +cflags-$(CONFIG_CC_IS_CLANG) += -fno-jump-tables
>
> So, shouldn't we just use -fno-jump-tables for *all* compilers,
> like we do in arch/x86/boot/startup/Makefile?
>
> The point wouldn't be to just work around any Clang
> jump-table optimization complications alone, but also
> to synchronize the build options of very early code and such.
I'm sitting on a patch to unconditionally disable jump-tables for
x86_64:
https://web.git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=x86/syscall
I need to fix the robot fallout and then actually post this.
next prev parent reply other threads:[~2026-06-24 9:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-23 21:47 [PATCH] x86/boot/compressed: Disable jump tables for clang Nathan Chancellor
2026-06-24 9:36 ` Ingo Molnar
2026-06-24 9:38 ` Peter Zijlstra [this message]
2026-06-24 9:51 ` Ingo Molnar
2026-06-24 9:55 ` Ingo Molnar
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=20260624093848.GA48970@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=justinstitt@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=stable@vger.kernel.org \
--cc=tglx@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox