The elf_create_file() function fails with EINVAL when the build directory
path is long enough to truncate the "XXXXXX" suffix in the 256-byte
tmp_name buffer.
Simplify the code to remove the unnecessary dirname()/basename() split
and concatenation. Instead, allocate the exact number of bytes needed for
the path.
Acked-by: Song Liu <song@kernel.org>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Link: https://patch.msgid.link/20260310203751.1479229-3-joe.lawrence@redhat.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Commit 356e4b2f5b ("objtool: Fix data alignment in elf_add_data()")
corrected the alignment of data within a section (honoring the section's
sh_addralign). Apply the same alignment when klp-diff mode clones a
symbol, adjusting the new symbol's offset for the output section's
sh_addralign.
Fixes: dd590d4d57 ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Link: https://patch.msgid.link/20260310203751.1479229-2-joe.lawrence@redhat.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Pull objtool fixes from Ingo Molnar:
- Fix cross-build bug by using HOSTCFLAGS for HAVE_XXHASH test
- Fix klp bug by fixing detection of corrupt static branch/call entries
- Handle unsupported pr_debug() usage more gracefully
- Fix hypothetical klp bug by avoiding NULL pointer dereference when
printing code symbol name
- Fix data alignment bug in elf_add_data() causing mangled strings
- Fix confusing ERROR_INSN() error message
- Handle unexpected Clang RSP musical chairs causing false positive
warnings
- Fix another objtool stack overflow in validate_branch()
* tag 'objtool-urgent-2026-03-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
objtool: Fix another stack overflow in validate_branch()
objtool: Handle Clang RSP musical chairs
objtool: Fix ERROR_INSN() error message
objtool: Fix data alignment in elf_add_data()
objtool: Use HOSTCFLAGS for HAVE_XXHASH test
objtool/klp: Avoid NULL pointer dereference when printing code symbol name
objtool/klp: Disable unsupported pr_debug() usage
objtool/klp: Fix detection of corrupt static branch/call entries
Previously, HAVE_XXHASH is tested by invoking HOSTCC without HOSTCFLAGS.
Consider the following scenario:
- The host machine has libxxhash installed
- We build the kernel with HOSTCFLAGS containing a --sysroot that does
not have xxhash.h (for hermetic builds)
In this case, HAVE_XXHASH is set to y, but when it builds objtool with
HOSTCFLAGS, because the --sysroot does not contain xxhash.h, the
following error is raised:
<...>/common/tools/objtool/include/objtool/checksum_types.h:12:10: fatal error: 'xxhash.h' file not found
12 | #include <xxhash.h>
| ^~~~~~~~~~
To resolve the error, we test HAVE_XXHASH by invoking HOSTCC with
HOSTCFLAGS.
Signed-off-by: HONG Yifan <elsk@google.com>
Reviewed-by: Carlos Llamas <cmllamas@google.com>
Link: https://patch.msgid.link/20260303010340.306164-1-elsk@google.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Patching a function which references a static key living in a kernel
module is unsupported due to ordering issues inherent to late module
patching:
1) Load a livepatch module which has a __jump_table entry which needs
a klp reloc to reference static key K which lives in module M.
2) The __jump_table klp reloc does *not* get resolved because module M
is not yet loaded.
3) jump_label_add_module() corrupts memory (or causes a panic) when
dereferencing the uninitialized pointer to key K.
validate_special_section_klp_reloc() intends to prevent that from ever
happening by catching it at build time. However, it incorrectly assumes
the special section entry's reloc symbol references have already been
converted from section symbols to object symbols, causing the validation
to miss corruption in extracted static branch/call table entries.
Make sure the references have been properly converted before doing the
validation.
Fixes: dd590d4d57 ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Reported-by: Song Liu <song@kernel.org>
Reviewed-and-tested-by: Song Liu <song@kernel.org>
Link: https://patch.msgid.link/124ad747b751df0df1725eff89de8332e3fb26d6.1770759954.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
The difference between 'make clean' and 'make mrproper' is documented in
'make help' as:
clean - Remove most generated files but keep the config and
enough build support to build external modules
mrproper - Remove all generated files + config + various backup files
After commit 68b4fe32d7 ("kbuild: Add objtool to top-level clean
target"), running 'make clean' then attempting to build an external
module with the resulting build directory fails with
$ make ARCH=x86_64 O=build clean
$ make -C build M=... MO=...
...
/bin/sh: line 1: .../build/tools/objtool/objtool: No such file or directory
as 'make clean' removes the objtool binary.
Split the objtool clean target into mrproper and clean like Kbuild does
and remove all generated artifacts with 'make clean' except for the
objtool binary, which is removed with 'make mrproper'. To avoid a small
race when running the objtool clean target through both objtool_mrproper
and objtool_clean when running 'make mrproper', modify objtool's clean
up find command to avoid using find's '-delete' command by piping the
files into 'xargs rm -f' like the rest of Kbuild does.
Cc: stable@vger.kernel.org
Fixes: 68b4fe32d7 ("kbuild: Add objtool to top-level clean target")
Reported-by: Michal Suchanek <msuchanek@suse.de>
Closes: https://lore.kernel.org/20260225112633.6123-1-msuchanek@suse.de/
Reported-by: Rainer Fiebig <jrf@mailbox.org>
Closes: https://lore.kernel.org/62d12399-76e5-3d40-126a-7490b4795b17@mailbox.org/
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Tested-by: Nicolas Schier <nsc@kernel.org>
Link: https://patch.msgid.link/20260227-avoid-objtool-binary-removal-clean-v1-1-122f3e55eae9@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Pull rust fixes from Miguel Ojeda:
"Toolchain and infrastructure:
- Pass '-Zunstable-options' flag required by the future Rust 1.95.0
- Fix 'objtool' warning for Rust 1.84.0
'kernel' crate:
- 'irq' module: add missing bound detected by the future Rust 1.95.0
- 'list' module: add missing 'unsafe' blocks and placeholder safety
comments to macros (an issue for future callers within the crate)
'pin-init' crate:
- Clean Clippy warning that changed behavior in the future Rust
1.95.0"
* tag 'rust-fixes-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
rust: list: Add unsafe blocks for container_of and safety comments
rust: pin-init: replace clippy `expect` with `allow`
rust: irq: add `'static` bounds to irq callbacks
objtool/rust: add one more `noreturn` Rust function
rust: kbuild: pass `-Zunstable-options` for Rust 1.95.0
Pull Kbuild fixes from Nathan Chancellor:
- Ensure tools/objtool is cleaned by 'make clean' and 'make mrproper'
- Fix test program for CONFIG_CC_CAN_LINK to avoid a warning, which is
made fatal by -Werror
- Drop explicit LZMA parallel compression in scripts/make_fit.py
- Several fixes for commit 62089b8048 ("kbuild: rpm-pkg: Generate
debuginfo package manually")
* tag 'kbuild-fixes-7.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux:
kbuild: rpm-pkg: Disable automatic requires for manual debuginfo package
kbuild: rpm-pkg: Fix manual debuginfo generation when using .src.rpm
kernel: rpm-pkg: Restore find-debuginfo.sh approach to -debuginfo package
kbuild: rpm-pkg: Restrict manual debug package creation
scripts/make_fit.py: Drop explicit LZMA parallel compression
kbuild: Fix CC_CAN_LINK detection
kbuild: Add objtool to top-level clean target
Pull x86 paravirt updates from Borislav Petkov:
- A nice cleanup to the paravirt code containing a unification of the
paravirt clock interface, taming the include hell by splitting the
pv_ops structure and removing of a bunch of obsolete code (Juergen
Gross)
* tag 'x86_paravirt_for_v7.0_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (23 commits)
x86/paravirt: Use XOR r32,r32 to clear register in pv_vcpu_is_preempted()
x86/paravirt: Remove trailing semicolons from alternative asm templates
x86/pvlocks: Move paravirt spinlock functions into own header
x86/paravirt: Specify pv_ops array in paravirt macros
x86/paravirt: Allow pv-calls outside paravirt.h
objtool: Allow multiple pv_ops arrays
x86/xen: Drop xen_mmu_ops
x86/xen: Drop xen_cpu_ops
x86/xen: Drop xen_irq_ops
x86/paravirt: Move pv_native_*() prototypes to paravirt.c
x86/paravirt: Introduce new paravirt-base.h header
x86/paravirt: Move paravirt_sched_clock() related code into tsc.c
x86/paravirt: Use common code for paravirt_steal_clock()
riscv/paravirt: Use common code for paravirt_steal_clock()
loongarch/paravirt: Use common code for paravirt_steal_clock()
arm64/paravirt: Use common code for paravirt_steal_clock()
arm/paravirt: Use common code for paravirt_steal_clock()
sched: Move clock related paravirt code to kernel/sched
paravirt: Remove asm/paravirt_api_clock.h
x86/paravirt: Move thunk macros to paravirt_types.h
...
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
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
164c9201e1 ("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 860238af7a ("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: 164c9201e1 ("objtool: Add base objtool support for livepatch modules")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Song Liu <song@kernel.org>
Tested-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/0bd3ae9a53c3d743417fe842b740a7720e2bcd1c.1770058775.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
When compiling with CONFIG_LTO_CLANG_THIN, vmlinux.o has
__irf_[start|end] before the first FILE entry:
$ readelf -sW vmlinux.o
Symbol table '.symtab' contains 597706 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 NOTYPE LOCAL DEFAULT 18 __irf_start
2: 0000000000000200 0 NOTYPE LOCAL DEFAULT 18 __irf_end
3: 0000000000000000 0 SECTION LOCAL DEFAULT 17 .text
4: 0000000000000000 0 SECTION LOCAL DEFAULT 18 .init.ramfs
This causes klp-build warnings like:
vmlinux.o: warning: objtool: no correlation: __irf_start
vmlinux.o: warning: objtool: no correlation: __irf_end
The problem is that Clang LTO is stripping the initramfs_data.o FILE
symbol, causing those two symbols to be orphaned and not noticed by
klp-diff's correlation logic. Add a loop to correlate any symbols found
before the first FILE symbol.
Fixes: dd590d4d57 ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Reported-by: Song Liu <song@kernel.org>
Acked-by: Song Liu <song@kernel.org>
Link: https://patch.msgid.link/e21ec1141fc749b5f538d7329b531c1ab63a6d1a.1770055235.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
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 <petr.pavlu@suse.com>
Acked-by: Joe Lawrence <joe.lawrence@redhat.com>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
Link: https://patch.msgid.link/20260123102825.3521961-3-petr.pavlu@suse.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Pull objtool fixes from Ingo Molnar:
- Fix a build error on ia32-x86_64 cross builds
- Replace locally open coded ALIGN_UP(), ALIGN_UP_POW2()
and MAX(), which, beyond being duplicates, the
ALIGN_UP_POW2() is also buggy
- Fix objtool klp-diff regression caused by a recent
change to the bug table format
- Fix klp-build vs CONFIG_MODULE_SRCVERSION_ALL build
failure
* tag 'objtool-urgent-2026-02-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
livepatch/klp-build: Fix klp-build vs CONFIG_MODULE_SRCVERSION_ALL
objtool/klp: Fix bug table handling for __WARN_printf()
objtool: Replace custom macros in elf.c with shared ones
objtool: Print bfd_vma as unsigned long long on ia32-x86_64 cross build
Pull Rust fixes from Miguel Ojeda:
"Toolchain and infrastructure:
- Trigger rebuilds of the newly added 'proc-macro2' crate (and its
dependencies) when the Rust compiler version changes
- Fix error in '.rsi' targets (macro expanding single targets) under
'O=' pointing to an external (not subdir) folder
- Fix off-by-one line number in 'rustdoc' KUnit tests
- Add '-fdiagnostics-show-context' to GCC flags skipped by 'bindgen'
- Clean objtool warning by adding one more 'noreturn' function
- Clean 'libpin_init_internal.{so,dylib}' in 'mrproper'
'kernel' crate:
- Fix build error when using expressions in formatting arguments
- Mark 'num::Bounded::__new()' as unsafe and clean documentation
accordingly
- Always inline functions using 'build_assert' with arguments
- Fix 'rusttest' build error providing the right 'isize_atomic_repr'
type for the host
'macros' crate:
- Fix 'rusttest' build error by ignoring example
rust-analyzer:
- Remove assertion that was not true for distributions like NixOS
- Add missing dependency edges and fix editions for 'quote' and
sysroot crates to provide correct IDE support
DRM Tyr:
- Fix build error by adding missing dependency on 'CONFIG_COMMON_CLK'
Plus clean a few typos in docs and comments"
* tag 'rust-fixes-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (28 commits)
rust: num: bounded: clean __new documentation and comments
scripts: generate_rust_analyzer: fix resolution of #[pin_data] macros
drm/tyr: depend on `COMMON_CLK` to fix build error
rust: sync: atomic: Provide stub for `rusttest` 32-bit hosts
kbuild: rust: clean libpin_init_internal in mrproper
rust: proc-macro2: rebuild if the version text changes
rust: num: bounded: add missing comment for always inlined function
rust: sync: refcount: always inline functions using build_assert with arguments
rust: bits: always inline functions using build_assert with arguments
scripts: generate_rust_analyzer: compile sysroot with correct edition
scripts: generate_rust_analyzer: compile quote with correct edition
scripts: generate_rust_analyzer: quote: treat `core` and `std` as dependencies
scripts: generate_rust_analyzer: syn: treat `std` as a dependency
scripts: generate_rust_analyzer: remove sysroot assertion
rust: kbuild: give `--config-path` to `rustfmt` in `.rsi` target
scripts: generate_rust_analyzer: Add pin_init_internal deps
scripts: generate_rust_analyzer: Add pin_init -> compiler_builtins dep
scripts: generate_rust_analyzer: Add compiler_builtins -> core dep
rust: macros: ignore example with module parameters
rust: num: bounded: mark __new as unsafe
...
Running objtool klp-diff on a changed function which uses WARN() can
fail with:
vmlinux.o: error: objtool: md_run+0x866: failed to convert reloc sym '__bug_table' to its proper format
The problem is that since commit 5b472b6e5b ("x86_64/bug: Implement
__WARN_printf()"), each __WARN_printf() call site now directly
references its bug table entry. klp-diff errors out when it can't
convert such section-based references to object symbols (because bug
table entries don't have symbols).
Luckily, klp-diff already has code to create symbols for bug table
entries. Move that code earlier, before function diffing.
Fixes: dd590d4d57 ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Fixes: 5b472b6e5b ("x86_64/bug: Implement __WARN_printf()")
Reported-by: Song Liu <song@kernel.org>
Tested-by: Song Liu <song@kernel.org>
Link: https://patch.msgid.link/a8e0a714b9da962858842b9aecd63b4900927c88.1769406850.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
The source file tools/objtool/elf.c defines the macros ALIGN_UP(),
ALIGN_UP_POW2() and MAX(). These macros unnecessarily duplicate
functionality already available under tools/include/, specifically ALIGN(),
roundup_pow_of_two() and max().
More importantly, the definition of ALIGN_UP_POW2() is incorrect when the
input is 1, as it results in a call to __builtin_clz(0), which produces an
undefined result. This issue impacts the function elf_alloc_reloc(). When
adding the first relocation to a section, the function allocates an
undefined number of relocations.
Replace the custom macros with the shared functionality to resolve these
issues.
Fixes: 2c05ca0262 ("objtool: Add elf_create_reloc() and elf_init_reloc()")
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Link: https://patch.msgid.link/20260126151356.3924887-1-petr.pavlu@suse.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
When objtool is cross-compiled in ia32 container for x86_64 target it
fails with the following errors:
> disas.c: In function 'disas_print_addr_sym':
> disas.c:173:38: error: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'bfd_vma' {aka 'long long unsigned int'} [-Werror=format=]
> 173 | DINFO_FPRINTF(dinfo, "0x%lx <%s>", addr, symstr);
> | ^~~~~~~~~~~~ ~~~~
> | |
> | bfd_vma {aka long long unsigned int}
Provide a correct printf-fmt depending on sizeof(bfd_vma).
Fixes: 5d859dff26 ("objtool: Print symbol during disassembly")
Signed-off-by: Dmitry Safonov <dima@arista.com>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Link: https://patch.msgid.link/20260126-objtool-ia32-v1-1-bb6feaf17566@arista.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Commit 436326bc52 ("objtool: fix build failure due to missing libopcodes
check") tests for libopcodes using an empty main(), which passes even when
static libraries lack their dependencies. This causes undefined reference
errors (xmalloc, bfd_get_bits, etc.) when linking against static libopcodes
without its required libbfd and libiberty.
Fix by testing with an actual libopcodes symbol and trying increasingly
complete library combinations until one succeeds.
Fixes: 436326bc52 ("objtool: fix build failure due to missing libopcodes check")
Reported-by: Rafael J. Wysocki <rafael@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Link: https://patch.msgid.link/20260121162532.1596238-1-sashal@kernel.org
Having a single large pv_ops array has the main disadvantage of needing all
prototypes of the single array members in one header file. This is adding up
to the need to include lots of otherwise unrelated headers.
In order to allow multiple smaller pv_ops arrays dedicated to one area of the
kernel each, allow multiple arrays in objtool.
For better performance limit the possible names of the arrays to start with
"pv_ops".
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260105110520.21356-19-jgross@suse.com
Commit 5995330382 ("objtool: Disassemble code with libopcodes instead
of running objdump") added support for using libopcodes for disassembly.
However, the feature detection checks for libbfd availability but then
unconditionally links against libopcodes:
ifeq ($(feature-libbfd),1)
OBJTOOL_LDFLAGS += -lopcodes
endif
This causes build failures in environments where libbfd is installed but
libopcodes is not, since the test-libbfd.c feature test only links
against -lbfd and -ldl, not -lopcodes:
/usr/bin/ld: cannot find -lopcodes: No such file or directory
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:109: objtool] Error 1
Additionally, the shared feature framework uses $(CC) which is the
cross-compiler in cross-compilation builds. Since objtool is a host tool
that links with $(HOSTCC) against host libraries, the feature detection
can falsely report libopcodes as available when the cross-compiler's
sysroot has it but the host system doesn't.
Fix this by replacing the feature framework check with a direct inline
test that uses $(HOSTCC) to compile and link a test program against
libopcodes, similar to how xxhash availability is detected.
Fixes: 5995330382 ("objtool: Disassemble code with libopcodes instead of running objdump")
Assisted-by: claude-opus-4-5-20251101
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20251223120357.2492008-1-sashal@kernel.org
When using the x32 toolchain, compilation fails because the printf
specifier "%lx" (long), doesn't match the type of the "checksum" variable
(long long). Fix this by changing the printf specifier to "%llx" and
casting "checksum" to unsigned long long.
Fixes: a3493b3338 ("objtool/klp: Add --debug-checksum=<funcs> to show per-instruction checksums")
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/a1158c99-fe0e-a218-4b5b-ffac212489f6@redhat.com
Instead of having a pre-filled array xen_mmu_ops for Xen PV paravirt
functions, drop the array and assign each element individually.
This is in preparation of reducing the paravirt include hell by
splitting paravirt.h into multiple more fine grained header files,
which will in turn require to split up the pv_ops vector as well.
Dropping the pre-filled array makes life easier for objtool to
detect missing initializers in multiple pv_ops_ arrays.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://patch.msgid.link/20260105110520.21356-18-jgross@suse.com
Instead of having a pre-filled array xen_cpu_ops for Xen PV paravirt
functions, drop the array and assign each element individually.
This is in preparation of reducing the paravirt include hell by
splitting paravirt.h into multiple more fine grained header files,
which will in turn require to split up the pv_ops vector as well.
Dropping the pre-filled array makes life easier for objtool to
detect missing initializers in multiple pv_ops_ arrays.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://patch.msgid.link/20260105110520.21356-17-jgross@suse.com
Instead of having a pre-filled array xen_irq_ops for Xen PV paravirt
functions, drop the array and assign each element individually.
This is in preparation of reducing the paravirt include hell by
splitting paravirt.h into multiple more fine grained header files,
which will in turn require to split up the pv_ops vector as well.
Dropping the pre-filled array makes life easier for objtool to
detect missing initializers in multiple pv_ops_ arrays.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://patch.msgid.link/20260105110520.21356-16-jgross@suse.com
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 51d9ee90ea ("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: 51d9ee90ea ("rust: str: add radix prefixed integer parsing functions")
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Tested-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20251223113538.1016078-1-fujita.tomonori@gmail.com
[ Reworded typo. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
When the kernel build fails due to an objtool segfault, the error
message is a bit obtuse and confusing:
make[5]: *** [scripts/Makefile.build:503: drivers/scsi/qla2xxx/qla2xxx.o] Error 139
^^^^^^^^^
make[5]: *** Deleting file 'drivers/scsi/qla2xxx/qla2xxx.o'
make[4]: *** [scripts/Makefile.build:556: drivers/scsi/qla2xxx] Error 2
make[3]: *** [scripts/Makefile.build:556: drivers/scsi] Error 2
make[2]: *** [scripts/Makefile.build:556: drivers] Error 2
make[1]: *** [/home/jpoimboe/git/linux/Makefile:2013: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2
Add a signal handler to objtool which prints an error message like if
the local stack has overflown (for which there's a chance as objtool
makes heavy use of recursion):
drivers/scsi/qla2xxx/qla2xxx.o: error: SIGSEGV: objtool stack overflow!
or:
drivers/scsi/qla2xxx/qla2xxx.o: error: SIGSEGV: objtool crash!
Also, re-raise the signal so the core dump still gets triggered.
[ mingo: Applied a build fix, added more comments and prettified the code. ]
Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>
Cc: David Laight <david.laight.linux@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/mi4tihk4dbncn7belrhp6ooudhpw4vdggerktu5333w3gqf3uf@vqlhc3y667mg
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 <nathan@kernel.org>
Fixes: fcb268b47a ("objtool: Trace instruction state changes during function validation")
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/21bb161c23ca0d8c942a960505c0d327ca2dc7dc.1764691895.git.jpoimboe@kernel.org
Closes: https://lore.kernel.org/20251201202329.GA3225984@ax162
Building objtool with disassembly support can fail when including
the bdf.h file:
In file included from tools/objtool/include/objtool/arch.h:108,
from check.c:14:
/usr/include/bfd.h:35:2: error: #error config.h must be included before this header
35 | #error config.h must be included before this header
| ^~~~~
This check is present in the bfd.h file generated from the binutils
source code, but it is not necessarily present in the bfd.h file
provided in a binutil package (for example, it is not present in
the binutil RPM).
The solution to this issue is to define the PACKAGE macro before
including bfd.h. This is the solution suggested by the binutil
developer in bug 14243, and it is used by other kernel tools
which also use bfd.h (perf and bpf).
Fixes: 5995330382 ("objtool: Disassemble code with libopcodes instead of running objdump")
Closes: https://lore.kernel.org/all/3fa261fd-3b46-4cbe-b48d-7503aabc96cb@oracle.com/
Reported-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=14243
Link: https://patch.msgid.link/20251126134519.1760889-1-alexandre.chartre@oracle.com
When using the --disas option, alternatives are disassembled but
address references in non-default alternatives can be incorrect.
The problem is that alternatives are shown as if they were replacing the
original code of the alternative. So if an alternative is referencing
an address inside the alternative then the reference has to be
adjusted to the location of the original code.
Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
Link: https://patch.msgid.link/20251121095340.464045-25-alexandre.chartre@oracle.com
All alternatives are disassemble side-by-side when using the --disas
option. However the address of each instruction is not printed because
instructions from different alternatives are not necessarily aligned.
Change this behavior to print the address of each instruction. Spaces
will appear between instructions from the same alternative when
instructions from different alternatives do not have the same alignment.
Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
Link: https://patch.msgid.link/20251121095340.464045-22-alexandre.chartre@oracle.com
