kernel/git/next/linux-next.git/tools/objtool, branch master

Merge branch 'rust-fixes' of https://github.com/Rust-for-Linux/linux.git

2026-08-28T12:34:32+00:00

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

2026-08-23T19:27:16+00:00

When the pointer formatting series [1] is applied and KUnit tests are enabled, `objtool` would report an error with any of our supported Rust versions. For instance, with Rust 1.97.1: rust/kernel.o: error: objtool: _R..._4core3fmt7Pointer3fmtB7_() falls through to next function _R..._4core7convert5AsRefNtB5_4BStrE6as_ref() Or, with Rust 1.85.0: rust/kernel.o: error: objtool: _R..._4core3fmt7Pointer3fmtB7_() falls through to next function _R..._4core3ffi5c_str4CStrENtNtBS_3fmt7Display3fmtB7_() This happens due to calls to the `noreturn` symbol: core::str::slice_error_fail Thus add the mangled one to the list so that `objtool` knows it is actually `noreturn`. See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions") for more details. [ While the series [1] mentioned above was not applied in a way that triggered this, Gary found another case [2]: I am seeing this function causing issue on my 1.85.1 -Os build, although the error message is different this time: rust/kernel.o: warning: objtool: _R..._5range9RangeFromjEE5indexCsldbe0TGTmNx_6kernel+0x1d: stack state mismatch: cfa1=4+8 cfa2=4+16 Disassembly shows that the function call before the warning location is a call to _4core3str16slice_error_fail, and objtool thought it can return (which will end up with a unbalanced stack if it does return). Thus apply it. - Miguel ] Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Cc: Josh Poimboeuf Cc: Peter Zijlstra Reported-by: Alice Ryhl Link: https://lore.kernel.org/rust-for-linux/anLxXvCKBcAVf91_@google.com/ Link: https://lore.kernel.org/rust-for-linux/20260706-hashedptr-v13-0-377a07f2f78d@kylinos.cn/ [1] Link: https://lore.kernel.org/rust-for-linux/DKS7U9UHY6XR.2JC0EBIPCI06Z@garyguo.net/ [2] Link: https://patch.msgid.link/20260805144524.233362-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda

Merge tag 'efi-next-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi

2026-08-23T16:24:34+00:00

Pull EFI updates from Ard Biesheuvel: - Set a timeout for EFI runtime service completions, and declare the firmware wedged if it is exceeded. Note that this requires special handling in case the firmware does return after all - Rate limit the efivarfs statfs() handler as the QueryVariableInfo() runtime service can be costly - Sanity check the size of struct properties_header on Mac/x86 - Tweak the prototype of efi_guid_to_str() * tag 'efi-next-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efivarfs: Rate limit statfs() handler efi: apple-properties: validate setup data header length efi: make efi_guid_to_str() take a const GUID pointer efi/runtime-wrappers: retire the worker if a wedged call ever returns efi/runtime-wrappers: honour EFI_RUNTIME_SERVICES in the non-blocking paths efi/runtime-wrappers: bound the wait for EFI runtime service calls efi/runtime-wrappers: check EFI_RUNTIME_SERVICES before using efi_rts_work efi/runtime-wrappers: handle queue_work() failure with goto exit efi/runtime-wrappers: factor out efi_rts_park_worker() efi: fix stale reference to efi_recover_from_page_fault()

efi/runtime-wrappers: factor out efi_rts_park_worker()

2026-08-20T11:45:04+00:00

x86's efi_crash_gracefully_on_page_fault() ends in an infinite schedule() loop so the kworker that faulted in firmware never runs efi_rts_wq again. A later change needs the same "park this worker forever" primitive on the runtime service timeout path, so factor the loop into a shared efi_rts_park_worker() and call it from the x86 page-fault handler. No functional change. Signed-off-by: Breno Leitao Signed-off-by: Ard Biesheuvel

Merge tag 'x86_alternatives_for_v7.3_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-08-19T01:11:25+00:00

Pull x86 alternatives update from Borislav Petkov: - Remove the smp_locks alternatives machinery which was used to patch out lock prefixes when running a SMP kernel on a uniprocessor machine * tag 'x86_alternatives_for_v7.3_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/alternative: Drop smp_locks glue

Merge tag 'objtool-core-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-08-18T19:18:33+00:00

Pull objtool updates from Ingo Molnar: - Fix various klp-build bugs reported by Joe Lawrence (Josh Poimboeuf, Joe Lawrence) - Misc fixes and cleanups (Puranjay Mohan, Thomas Huth and Ingo Molnar) * tag 'objtool-core-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool/klp: Fix vmlinux klp relocations for EXPORT_SYMBOL_FOR_MODULES() objtool/klp: Fix .kcfi_traps special section extraction objtool/klp: Fix vmlinux .klp.symid link error for .exitcall.exit symbols objtool/klp: Fix line numbers in Module.symvers parse errors objtool/klp: Fix relocations for EXPORT_SYMBOL_FOR_MODULES() symbols objtool/klp: Allow new references to module exports objtool/klp: Don't match local symbols against exports objtool/klp: Fix cross-module klp relocation section naming objtool/klp: Explicitly disallow patching or referencing init code/data objtool/klp: Ignore replacement offset of empty x86 alternatives objtool/klp: Fix size of empty special section entries objtool/klp: Fix vmlinux .klp.symid link error for .no_trim_symbol symbols objtool/headers: Sync tools/include/linux/objtool_types.h with include/linux/objtool_types.h objtool: Replace __ASSEMBLY__ with __ASSEMBLER__ in header files objtool/klp: Fix symbol resolution for duplicate data symbols objtool/klp: Add .klp.symid for sympos disambiguation objtool/klp: Skip hidden directories when finding objects objtool/klp: Fix false module dependencies caused by dead relocs objtool/klp: Normalize Module.symvers paths to module names objtool/klp: Fix module name normalization for paths with dots

objtool/klp: Fix vmlinux klp relocations for EXPORT_SYMBOL_FOR_MODULES()

2026-08-17T08:53:55+00:00

When a module function references a vmlinux symbol which is exported with EXPORT_SYMBOL_FOR_MODULES(), a patch to that function needs to use a klp reloc. Currently, livepatch fails to load such a module: livepatch: invalid access to vmlinux symbol 'get_task_policy' from module-specific livepatch relocation section livepatch: failed to initialize patch 'livepatch_test' for module 'testmod' (-22) livepatch: patch 'livepatch_test' failed for module 'testmod', refusing to load module 'testmod' klp diff puts all klp relocs in __klp_relocs., so post-link names the section .klp.rela.., which the kernel rejects for vmlinux symbols. Commit 07f14d6af9d77 ("objtool/klp: Fix cross-module klp relocation section naming") changed the meaning of objname in the klp rela section name to be where the referenced symbol is referenced rather than where it lives. That premise only holds for symbols in a module: the relocs get applied when the patched module gets patched, and the module dependency guarantees the referenced module is loaded by then. A vmlinux symbol needs the opposite. It's always resolvable, and it has to be applied when the patch module loads, before the module loader initializes the patch module's special sections, which may reference it. That's why livepatch rejects vmlinux symbols in module-specific sections. Use "vmlinux" as the section objname when the referenced symbol lives in vmlinux. This moves such klp relocs from .klp.rela.kvm..text to .klp.rela.vmlinux..text. Fixes: 07f14d6af9d77 ("objtool/klp: Fix cross-module klp relocation section naming") Reported-by: Dylan Hatch Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Acked-by: Song Liu Link: https://patch.msgid.link/f8e3b9fae109903a6aafb2a33310e4afdcebf58e.1786761327.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/CADBMgpz7iWC0=t=_gE-tfvv0mTPq4kg0qQ2zgPH8DVPE6eQ9Kw@mail.gmail.com

objtool/klp: Fix .kcfi_traps special section extraction

2026-08-12T20:52:07+00:00

create_fake_symbols() creates a symbol per entry for special sections. It does so in two steps: first for the sections which have ANNOTATE_DATA_SPECIAL annotations, then for the rest, using entsize or the reloc count to infer the entry size. The second step skips the sections already handled by the first one by looking for a symbol at offset 0. That heuristic is too fuzzy: with Clang and CONFIG_CFI, it misfires on .kcfi_traps because Clang emits a .Ltmp* assembler-local label at the start of the section, so no symbols are created and clone_special_sections() extracts nothing. klp-build still reports SUCCESS, but the livepatch module has no __kcfi_traps section and the traps for the patched functions are lost. Look for the actual fake symbols created by the first step instead. Fixes: da4326573ae8d ("objtool/klp: Fix kCFI trap handling") Reported-by: Joe Lawrence Closes: https://lore.kernel.org/r/akQNqlfFC0T5pcMa@redhat.com Acked-by: Song Liu Link: https://patch.msgid.link/8faaead205b219607b6fc2359ae743be824056eb.1786230311.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf

objtool/klp: Fix vmlinux .klp.symid link error for .exitcall.exit symbols

2026-08-12T20:33:32+00:00

Building a kernel via klp-build fails to link: `__exitcall_aes_mod_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o `__exitcall_dax_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o `__exitcall_hid_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o `__exitcall_usb_serial_module_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o module_exit() on a built-in emits a static __exitcall_$fn pointer into .exitcall.exit, which vmlinux.lds.h discards unconditionally via EXIT_CALL. When two built-in translation units define a module_exit() function of the same name, the resulting local symbols collide, symid_needed() sees a duplicate and emits a .klp.symid entry for each, referencing symbols the linker then throws away. Same-named module_exit() functions are not rare: dax_exit drivers/dax/device.c, drivers/dax/fsdev.c hid_exit drivers/hid/hid-core.c, drivers/hid/usbhid/hid-core.c aes_mod_exit arch/arm64/crypto/aes-ce-ccm-glue.c, lib/crypto/aes.c usb_serial_module_exit module_usb_serial_driver() expands to this fixed name in each of its ~49 users The last one makes the collision structural rather than accidental: any kernel with two built-in USB serial drivers has it. This is not arch specific either; it only requires the objects to be built in rather than modular, which is why a monolithic config trips it while a typical distro config does not. Add .exitcall.exit to the discarded section list so its symbols don't get symids. This is the same failure mode as "objtool/klp: Fix vmlinux .klp.symid link error for .no_trim_symbol symbols", for another unconditionally discarded allocated section. Fixes: 029223d30162 ("objtool/klp: Add .klp.symid for sympos disambiguation") Signed-off-by: Puranjay Mohan Link: https://patch.msgid.link/m24igzlbxf.fsf@kernel.org Signed-off-by: Josh Poimboeuf

objtool/klp: Fix line numbers in Module.symvers parse errors

2026-08-11T23:10:58+00:00

read_exports() reports the offending line number when it fails to parse Module.symvers. The counter is initialized to 1 but never incremented, so every error blames line 1 regardless of where the bad line is. Acked-by: Joe Lawrence Acked-by: Song Liu Link: https://patch.msgid.link/133e16bb0c7cb916f10bbfb017eba525449ad1d6.1786138493.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf