Pull Rust fixes from Miguel Ojeda:
 "Toolchain and infrastructure:

   - Fix KCFI failures, such as in Rust doctests, by disabling function
     merging when CFI is enabled. Gary reported the LLVM bug to upstream
     and it is now fixed in their mainline.

   - Fix 'objtool' fallthrough warnings under the experimental
     'CONFIG_RUST_INLINE_HELPERS' by passing (for the combined Rust and
     helpers code) the LLVM options needed to preserve the unreachable
     traps that 'rustc' normally emits.

     In addition, fix 'objtool' errors when LTO is enabled on top, by
     also filtering out the LTO flags (for the combined Rust and helpers
     code) so that the traps are kept in place.

   - Fix 'objtool' warnings by adding one more 'noreturn' function.

   - Fix 'make rusttest' target when the 'rustc-dev' component is
     installed and Rust >= 1.82.0, <= 1.87.0 is used.

  'kernel' crate:

   - 'num' module: fix soundness issue in the 'Bounded' conversion from
     'bool' by restricting the conversions to unsigned 'Bounded'.

   - 'jump_label' module: fix future 'make rusttest' target failures
     when 'ARCH=' is set to an arch different than the host's.

   - 'list' module: fix incorrect 'pop_back()' comment"

* tag 'rust-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
  rust: kbuild: disambiguate `zerocopy_derive` for `rusttest`
  rust: num: restrict bool conversion to unsigned Bounded
  kbuild: rust: keep Rust objects out of Clang LTO with inline helpers
  kbuild: rust: preserve unreachable traps with inline helpers
  rust: cfi: disable function merging if CFI is enabled
  rust: jump_label: skip arch-specific asm in `testlib` builds
  objtool/rust: add one more `noreturn` Rust function
  rust: kernel: list: fix incorrect pop_back example comment

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 <jpoimboe@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Reported-by: Alice Ryhl <aliceryhl@google.com>
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 <ojeda@kernel.org>

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

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

Starting with Rust 1.99.0 (expected 2026-10-01), `objtool` may report:

    rust/kernel.o: warning: objtool: _R..._6kernel3str9parse_intaNtNtB2_7private12FromStrRadix14from_str_radix()
    falls through to next function _R..._6kernel3str9parse_intaNtNtB2_7private12FromStrRadix16from_u64_negated()

due to calls to the `noreturn` symbol:

    core::num::from_ascii_bytes_radix_panic

The function was renamed from `from_ascii_radix_panic` [1], which is
already in the list.

Thus add the new one to the list so that `objtool` knows it is actually
`noreturn`.

See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions")
for more details.

Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://github.com/rust-lang/rust/pull/159554 [1]
Tested-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260728191448.349241-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Livepatch identifies a duplicate-named symbol by its position (sympos)
among same-named kallsyms entries, which for vmlinux are counted in
ascending address order in the final linked kernel.  That order can't be
reliably derived from vmlinux.o: the final link reorders sub-sections
(.text.unlikely*, .data..*, etc).

Bridge the gap with a new .klp.symid section which can be used to
correlate symbols between vmlinux.o and vmlinux so that klp-diff can
reliably determine the sympos.

The table can't survive --gc-sections: keeping it alive would keep every
duplicate-named symbol's section alive, so the reference kernel would
stop matching the one which ships.  klp-build rejects
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION instead.  Nothing is lost today:
x86_64 is the only HAVE_KLP_BUILD arch and doesn't select
HAVE_LD_DEAD_CODE_DATA_ELIMINATION, arm64 and s390 have never selected
it either, and on powerpc, it's still EXPERIMENTAL and disabled by every
distro kernel.

This is the build-time half of reliable vmlinux sympos computation;
"objtool klp diff" will consume the table in a subsequent commit.

Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: live-patching@vger.kernel.org
Link: https://patch.msgid.link/64d50f077b569f47883c015cdb7079edb068efe8.1785727106.git.jpoimboe@kernel.org

This was there to be able to patch out locking instructions when running
a SMP kernel build on a UP CPU. The times are long gone when single-CPU
x86 machines were relevant so drop that machinery and simplify the code
considerably.

LOCK_PREFIX needs to stay for when one wants to do a UP build for
whatever reason. That'll go away when CONFIG_SMP becomes unconditional.

Kill a bunch of leftover, unused prototypes while at it.

Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://lore.kernel.org/r/20260328081634.797552-1-rppt@kernel.org

Starting with Rust 1.99.0 (expected 2026-10-01), under
`CONFIG_RUST_DEBUG_ASSERTIONS=y`, `objtool` may report:

    rust/kernel.o: warning: objtool: _R..._6kernel12module_param9set_paramaEB4_()
    falls through to next function _R..._6kernel12module_param9set_paramhEB4_()

(and many others) due to calls to the `noreturn` symbol [1]:

    core::panicking::panic_null_reference_constructed

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.

Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Petr Pavlu <petr.pavlu@suse.com>
Link: https://github.com/rust-lang/rust/pull/158796 [1]
Reported-by: Alice Ryhl <aliceryhl@google.com>
Closes: https://lore.kernel.org/rust-for-linux/alEBInX9gD1M5NAr@google.com/
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Tested-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260710173252.191781-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Only create prefix symbols for functions that have
__patchable_function_entries entries, since those are the only C
functions where prefix NOPs are intentional.

This both simplifies the detection and makes it more accurate.

Note that assembly functions using SYM_TYPED_FUNC_START() can also have
prefixed NOPs, but that macro already creates their __cfi_ symbols.

Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>

For all CONFIG_CFI+CONFIG_CALL_PADDING configs, for C functions, the
__cfi_ symbols only cover the 5-byte kCFI type hash.  After that there
also N bytes of NOP padding between the hash and the function entry
which aren't associated with any symbol.

The NOPs can be replaced with actual code at runtime.  Without a symbol,
unwinders and tooling have no way of knowing where those bytes belong.

Grow the existing __cfi_* symbols to fill that gap.

Note that assembly functions with SYM_TYPED_FUNC_START() aren't affected
by this issue, their __cfi_ symbols also cover the padding.

Also, CONFIG_PREFIX_SYMBOLS has no reason to exist: CONFIG_CALL_PADDING
is what causes the compiler to emit NOP padding before function entry
(via -fpatchable-function-entry), so it's the right condition for
creating prefix symbols.

Remove CONFIG_PREFIX_SYMBOLS, as it's no longer needed.  Simplify the
LONGEST_SYM_KUNIT_TEST dependency accordingly.  Rework objtool's
arguments a bit to handle the variety of prefix/cfi-related cases.

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>