kernel/linux.git/arch/x86/tools, branch v6.6.132

x86/tools: Drop duplicate unlikely() definition in insn_decoder_test.c

2025-07-06T09:00:16+00:00

commit f710202b2a45addea3dcdcd862770ecbaf6597ef upstream. After commit c104c16073b7 ("Kunit to check the longest symbol length"), there is a warning when building with clang because there is now a definition of unlikely from compiler.h in tools/include/linux, which conflicts with the one in the instruction decoder selftest: arch/x86/tools/insn_decoder_test.c:15:9: warning: 'unlikely' macro redefined [-Wmacro-redefined] Remove the second unlikely() definition, as it is no longer necessary, clearing up the warning. Fixes: c104c16073b7 ("Kunit to check the longest symbol length") Signed-off-by: Nathan Chancellor Signed-off-by: Ingo Molnar Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20250318-x86-decoder-test-fix-unlikely-redef-v1-1-74c84a7bf05b@kernel.org Signed-off-by: Greg Kroah-Hartman

Kunit to check the longest symbol length

2025-07-06T09:00:16+00:00

commit c104c16073b7fdb3e4eae18f66f4009f6b073d6f upstream. The longest length of a symbol (KSYM_NAME_LEN) was increased to 512 in the reference [1]. This patch adds kunit test suite to check the longest symbol length. These tests verify that the longest symbol length defined is supported. This test can also help other efforts for longer symbol length, like [2]. The test suite defines one symbol with the longest possible length. The first test verify that functions with names of the created symbol, can be called or not. The second test, verify that the symbols are created (or not) in the kernel symbol table. [1] https://lore.kernel.org/lkml/20220802015052.10452-6-ojeda@kernel.org/ [2] https://lore.kernel.org/lkml/20240605032120.3179157-1-song@kernel.org/ Link: https://lore.kernel.org/r/20250302221518.76874-1-sergio.collado@gmail.com Tested-by: Martin Rodriguez Reboredo Reviewed-by: Shuah Khan Reviewed-by: Rae Moar Signed-off-by: Sergio González Collado Link: https://github.com/Rust-for-Linux/linux/issues/504 Reviewed-by: Rae Moar Acked-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman

x86/boot: Ignore relocations in .notes sections in walk_relocs() too

2024-06-12T09:11:36+00:00

[ Upstream commit 76e9762d66373354b45c33b60e9a53ef2a3c5ff2 ] Commit: aaa8736370db ("x86, relocs: Ignore relocations in .notes section") ... only started ignoring the .notes sections in print_absolute_relocs(), but the same logic should also by applied in walk_relocs() to avoid such relocations. [ mingo: Fixed various typos in the changelog, removed extra curly braces from the code. ] Fixes: aaa8736370db ("x86, relocs: Ignore relocations in .notes section") Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Signed-off-by: Guixiong Wei Signed-off-by: Ingo Molnar Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20240317150547.24910-1-weiguixiong@bytedance.com Signed-off-by: Sasha Levin

x86, relocs: Ignore relocations in .notes section

2024-03-26T22:19:35+00:00

[ Upstream commit aaa8736370db1a78f0e8434344a484f9fd20be3b ] When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmail.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross Signed-off-by: Kees Cook Signed-off-by: Sasha Levin

ELF: fix all "Elf" typos

2023-04-08T20:45:37+00:00

ELF is acronym and therefore should be spelled in all caps. I left one exception at Documentation/arm/nwfpe/nwfpe.rst which looks like being written in the first person. Link: https://lkml.kernel.org/r/Y/3wGWQviIOkyLJW@p183 Signed-off-by: Alexey Dobriyan Signed-off-by: Andrew Morton

kbuild: allow to combine multiple V= levels

2023-01-22T14:43:32+00:00

Commit a6de553da01c ("kbuild: Allow to combine multiple W= levels") supported W=123 to enable all the extra warning groups. I think a similar idea is applicable to the V= option. V=1 echos the whole command V=2 prints the reason for rebuilding These are orthogonal, and can be enabled at the same time. This commit supports V=12 to enable both of them. Signed-off-by: Masahiro Yamada Tested-by: Nicolas Schier Reviewed-by: Nicolas Schier

x86/tools/relocs: Ignore __kcfi_typeid_ relocations

2022-09-26T17:13:15+00:00

The compiler generates __kcfi_typeid_ symbols for annotating assembly functions with type information. These are constants that can be referenced in assembly code and are resolved by the linker. Ignore them in relocs. Signed-off-by: Sami Tolvanen Reviewed-by: Kees Cook Tested-by: Kees Cook Tested-by: Nathan Chancellor Acked-by: Peter Zijlstra (Intel) Tested-by: Peter Zijlstra (Intel) Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220908215504.3686827-20-samitolvanen@google.com

x86/build: Use the proper name CONFIG_FW_LOADER

2021-12-29T21:20:38+00:00

Commit in Fixes intends to add the expression regex only when FW_LOADER is enabled - not FW_LOADER_BUILTIN. Latter is a leftover from a previous patchset and not a valid config item. So, adjust the condition to the actual name of the config. [ bp: Cleanup commit message. ] Fixes: c8dcf655ec81 ("x86/build: Tuck away built-in firmware under FW_LOADER") Signed-off-by: Lukas Bulwahn Signed-off-by: Borislav Petkov Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20211229111553.5846-1-lukas.bulwahn@gmail.com

Merge tag 'driver-core-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2021-11-04T15:32:38+00:00

Pull driver core updates from Greg KH: "Here is the big set of driver core changes for 5.16-rc1. All of these have been in linux-next for a while now with no reported problems. Included in here are: - big update and cleanup of the sysfs abi documentation files and scripts from Mauro. We are almost at the place where we can properly check that the running kernel's sysfs abi is documented fully. - firmware loader updates - dyndbg updates - kernfs cleanups and fixes from Christoph - device property updates - component fix - other minor driver core cleanups and fixes" * tag 'driver-core-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (122 commits) device property: Drop redundant NULL checks x86/build: Tuck away built-in firmware under FW_LOADER vmlinux.lds.h: wrap built-in firmware support under FW_LOADER firmware_loader: move struct builtin_fw to the only place used x86/microcode: Use the firmware_loader built-in API firmware_loader: remove old DECLARE_BUILTIN_FIRMWARE() firmware_loader: formalize built-in firmware API component: do not leave master devres group open after bind dyndbg: refine verbosity 1-4 summary-detail gpiolib: acpi: Replace custom code with device_match_acpi_handle() i2c: acpi: Replace custom function with device_match_acpi_handle() driver core: Provide device_match_acpi_handle() helper dyndbg: fix spurious vNpr_info change dyndbg: no vpr-info on empty queries dyndbg: vpr-info on remove-module complete, not starting device property: Add missed header in fwnode.h Documentation: dyndbg: Improve cli param examples dyndbg: Remove support for ddebug_query param dyndbg: make dyndbg a known cli param dyndbg: show module in vpr-info in dd-exec-queries ...

x86/tools/relocs: Support >64K section headers

2021-10-27T09:07:58+00:00

While the relocs tool already supports finding the total number of section headers if vmlinux exceeds 64K sections, it fails to read the extended symbol table to get section header indexes for symbols, causing incorrect symbol table indexes to be used when there are > 64K symbols. Parse the ELF file to read the extended symbol table info, and then replace all direct references to st_shndx with calls to sym_index(), which will determine whether the value can be read directly or whether the value should be pulled out of the extended table. This is needed for future FGKASLR support, which uses a separate section per function. Signed-off-by: Kristen Carlson Accardi Signed-off-by: Alexander Lobakin Signed-off-by: Kees Cook Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kees Cook Reviewed-by: Tony Luck Acked-by: H. Peter Anvin (Intel) Tested-by: Tony Luck Link: https://lore.kernel.org/r/20211013175742.1197608-2-keescook@chromium.org