kernel/git/stable/linux.git/tools/objtool/check.c, branch linux-6.19.y

x86-64: rename misleadingly named '__copy_user_nocache()' function

2026-04-22T11:30:50+00:00

commit d187a86de793f84766ea40b9ade7ac60aabbb4fe upstream. This function was a masterclass in bad naming, for various historical reasons. It claimed to be a non-cached user copy. It is literally _neither_ of those things. It's a specialty memory copy routine that uses non-temporal stores for the destination (but not the source), and that does exception handling for both source and destination accesses. Also note that while it works for unaligned targets, any unaligned parts (whether at beginning or end) will not use non-temporal stores, since only words and quadwords can be non-temporal on x86. The exception handling means that it _can_ be used for user space accesses, but not on its own - it needs all the normal "start user space access" logic around it. But typically the user space access would be the source, not the non-temporal destination. That was the original intention of this, where the destination was some fragile persistent memory target that needed non-temporal stores in order to catch machine check exceptions synchronously and deal with them gracefully. Thus that non-descriptive name: one use case was to copy from user space into a non-cached kernel buffer. However, the existing users are a mix of that intended use-case, and a couple of random drivers that just did this as a performance tweak. Some of those random drivers then actively misused the user copying version (with STAC/CLAC and all) to do kernel copies without ever even caring about the exception handling, _just_ for the non-temporal destination. Rename it as a first small step to actually make it halfway sane, and change the prototype to be more normal: it doesn't take a user pointer unless the caller has done the proper conversion, and the argument size is the full size_t (it still won't actually copy more than 4GB in one go, but there's also no reason to silently truncate the size argument in the caller). Finally, use this now sanely named function in the NTB code, which mis-used a user copy version (with STAC/CLAC and all) of this interface despite it not actually being a user copy at all. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

objtool: Fix Clang jump table detection

2026-04-11T12:29:21+00:00

[ Upstream commit 4e5019216402ad0b4a84cff457b662d26803f103 ] With Clang, there can be a conditional forward jump between the load of the jump table address and the indirect branch. Fixes the following warning: vmlinux.o: warning: objtool: ___bpf_prog_run+0x1c5: sibling call from callable instruction with modified stack frame Reported-by: Arnd Bergmann Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com Link: https://patch.msgid.link/7d8600caed08901b6679767488acd639f6df9688.1773071992.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin

objtool: Handle Clang RSP musical chairs

2026-04-02T11:25:21+00:00

[ Upstream commit 7fdaa640c810cb42090a182c33f905bcc47a616a ] For no apparent reason (possibly related to CONFIG_KMSAN), Clang can randomly pass the value of RSP to other registers and then back again to RSP. Handle that accordingly. Fixes the following warnings: drivers/input/misc/uinput.o: warning: objtool: uinput_str_to_user+0x165: undefined stack state drivers/input/misc/uinput.o: warning: objtool: uinput_str_to_user+0x165: unknown CFA base reg -1 Reported-by: Arnd Bergmann Closes: https://lore.kernel.org/90956545-2066-46e3-b547-10c884582eb0@app.fastmail.com Link: https://patch.msgid.link/240e6a172cc73292499334a3724d02ccb3247fc7.1772818491.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin

objtool: Fix another stack overflow in validate_branch()

2026-03-19T15:15:07+00:00

[ Upstream commit 9a73f085dc91980ab7fcc5e9716f4449424b3b59 ] The insn state is getting saved on the stack twice for each recursive iteration. No need for that, once is enough. Fixes the following reported stack overflow: drivers/scsi/qla2xxx/qla_dbg.o: error: SIGSEGV: objtool stack overflow! Segmentation fault Fixes: 70589843b36f ("objtool: Add option to trace function validation") Reported-by: Arnd Bergmann Closes: https://lore.kernel.org/90956545-2066-46e3-b547-10c884582eb0@app.fastmail.com Link: https://patch.msgid.link/8b97f62d083457f3b0a29a424275f7957dd3372f.1772821683.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin

objtool/rust: add one more `noreturn` Rust function

2026-03-04T12:19:29+00:00

[ Upstream commit c431b00ca6afc5da3133636ecc34ee7edd38d6cc ] `objtool` with Rust 1.84.0 reports: rust/kernel.o: error: objtool: _RNvXNtNtCsaRPFapPOzLs_6kernel3str9parse_intaNtNtB2_7private12FromStrRadix14from_str_radix() falls through to next function _RNvXNtNtCsaRPFapPOzLs_6kernel3str9parse_intaNtNtB2_7private12FromStrRadix16from_u64_negated() This is very similar to commit c18f35e49049 ("objtool/rust: add one more `noreturn` Rust function"), which added `from_ascii_radix_panic` for Rust 1.86.0, except that Rust 1.84.0 ends up needing `from_str_radix_panic`. Thus add it to the list to fix the warning. Cc: FUJITA Tomonori Fixes: 51d9ee90ea90 ("rust: str: add radix prefixed integer parsing functions") Reported-by: Alice Ryhl Link: https://rust-for-linux.zulipchat.com/#narrow/channel/291565/topic/x/with/572427627 Tested-by: Alice Ryhl Link: https://patch.msgid.link/20260206204336.38462-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin

Merge tag 'objtool-urgent-2026-02-07' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-02-07T16:21:21+00:00

Pull objtool fixes from Ingo Molnar:: - Bump up the Clang minimum version requirements for livepatch builds, due to Clang assembler section handling bugs causing silent miscompilations - Strip livepatching symbol artifacts from non-livepatch modules - Fix livepatch build warnings when certain Clang LTO options are enabled - Fix livepatch build error when CONFIG_MEM_ALLOC_PROFILING_DEBUG=y * tag 'objtool-urgent-2026-02-07' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool/klp: Fix unexported static call key access for manually built livepatch modules objtool/klp: Fix symbol correlation for orphaned local symbols livepatch: Free klp_{object,func}_ext data after initialization livepatch: Fix having __klp_objects relics in non-livepatch modules livepatch/klp-build: Require Clang assembler >= 20

objtool/klp: Fix unexported static call key access for manually built livepatch modules

2026-02-05T16:00:45+00:00

Enabling CONFIG_MEM_ALLOC_PROFILING_DEBUG with CONFIG_SAMPLE_LIVEPATCH results in the following error: samples/livepatch/livepatch-shadow-fix1.o: error: objtool: static_call: can't find static_call_key symbol: __SCK__WARN_trap This is caused an extra file->klp sanity check which was added by commit 164c9201e1da ("objtool: Add base objtool support for livepatch modules"). That check was intended to ensure that livepatch modules built with klp-build always have full access to their static call keys. However, it failed to account for the fact that manually built livepatch modules (i.e., not built with klp-build) might need access to unexported static call keys, for which read-only access is typically allowed for modules. While the livepatch-shadow-fix1 module doesn't explicitly use any static calls, it does have a memory allocation, which can cause CONFIG_MEM_ALLOC_PROFILING_DEBUG to insert a WARN() call. And WARN() is now an unexported static call as of commit 860238af7a33 ("x86_64/bug: Inline the UD1"). Fix it by removing the overzealous file->klp check, restoring the original behavior for manually built livepatch modules. Fixes: 164c9201e1da ("objtool: Add base objtool support for livepatch modules") Reported-by: Arnd Bergmann Acked-by: Song Liu Tested-by: Arnd Bergmann Link: https://patch.msgid.link/0bd3ae9a53c3d743417fe842b740a7720e2bcd1c.1770058775.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf

livepatch: Free klp_{object,func}_ext data after initialization

2026-02-05T16:00:45+00:00

The klp_object_ext and klp_func_ext data, which are stored in the __klp_objects and __klp_funcs sections, respectively, are not needed after they are used to create the actual klp_object and klp_func instances. This operation is implemented by the init function in scripts/livepatch/init.c. Prefix the two sections with ".init" so they are freed after the module is initializated. Signed-off-by: Petr Pavlu Acked-by: Joe Lawrence Acked-by: Miroslav Benes Reviewed-by: Aaron Tomlin Link: https://patch.msgid.link/20260123102825.3521961-3-petr.pavlu@suse.com Signed-off-by: Josh Poimboeuf

objtool/rust: add one more `noreturn` Rust function

2026-01-04T22:51:35+00:00

Fix the following warning: rust/kernel.o: warning: objtool: _RNvXNtNtCs1ewLyjEZ7Le_6kernel3str9parse_intaNtNtB2_7private12FromStrRadix14from_str_radix() falls through to next function _RNvXNtNtCs1ewLyjEZ7Le_6kernel3str9parse_intaNtNtB2_7private12FromStrRadix16from_u64_negated() The commit 51d9ee90ea90 ("rust: str: add radix prefixed integer parsing functions") introduces u64::from_str_radix(), whose implementation contains a panic path for out-of-range radix values. The panic helper is core::num::from_ascii_radix_panic(). Note that radix is derived from strip_radix() here and is always within the valid range, so kernel never panics. Fixes: 51d9ee90ea90 ("rust: str: add radix prefixed integer parsing functions") Signed-off-by: FUJITA Tomonori Reviewed-by: Alice Ryhl Tested-by: Alice Ryhl Link: https://patch.msgid.link/20251223113538.1016078-1-fujita.tomonori@gmail.com [ Reworded typo. - Miguel ] Signed-off-by: Miguel Ojeda

objtool: Fix stack overflow in validate_branch()

2025-12-02T16:40:35+00:00

On an allmodconfig kernel compiled with Clang, objtool is segfaulting in drivers/scsi/qla2xxx/qla2xxx.o due to a stack overflow in validate_branch(). Due in part to KASAN being enabled, the qla2xxx code has a large number of conditional jumps, causing objtool to go quite deep in its recursion. By far the biggest offender of stack usage is the recently added 'prev_state' stack variable in validate_insn(), coming in at 328 bytes. Move that variable (and its tracing usage) to handle_insn_ops() and make handle_insn_ops() noinline to keep its stack frame outside the recursive call chain. Reported-by: Nathan Chancellor Fixes: fcb268b47a2f ("objtool: Trace instruction state changes during function validation") Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/21bb161c23ca0d8c942a960505c0d327ca2dc7dc.1764691895.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/20251201202329.GA3225984@ax162