modpost has a lot of error logging with module name, but the module name
is logged in a plethora of ways. Add struct module * parameter to
modpost_log(), and wrappers mod_warn() and mod_error(), to allow logging
with a unified module name, if provided.
If the module is provided, the messages will be of the format:
(ERROR|WARNING): modpost: (modname.ko|vmlinux): message
Actual conversion is done separately.
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patch.msgid.link/f27bd8810f0ef12fb86068f0190e4e0afa81e0fa.1786120005.git.jani.nikula@intel.com
Reviewed-by: Nathan Chancellor <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
Signed-off-by: Nicolas Schier <[email protected]>
The Kconfig frontend should render options that depend on a
previous option in the submenu of that previous option. But
currently, this breaks for negative dependencies. For example,
option FOO may be rendered in the submenu of option BAR, despite
FOO actually depending on !BAR.
Let's fix this ironic rendering by modifying Kconfig to explicitly
check negative dependencies.
I've only tested locally on x86, but as far as I can tell, this only
changes how 2 options are rendered in the menu:
1. NTFS3_FS, no longer in the NTFS_FS submenu, and
2. MTD_BLOCK_RO, no longer in the MTD_BLOCK submenu.
Tested-by: Nathan Chancellor <[email protected]>
Reported-by: Xi Ruoyao <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Assisted-by: Claude:claude-4.8-opus
Signed-off-by: Julian Braha <[email protected]>
Link: https://patch.msgid.link/[email protected]
Reviewed-by: Nicolas Schier <[email protected]>
Tested-by: Nicolas Schier <[email protected]>
Signed-off-by: Nicolas Schier <[email protected]>
HID drivers that rely on the HID core to register input devices must
ensure that all private data and capabilities (like force-feedback) are
fully initialized before registration.
When hid_hw_start() is called with HID_CONNECT_HIDINPUT, the input
device is registered immediately. This is racy if the driver attempts to
augment the input device in probe() after starting the hardware.
The correct way to handle this is to use the .input_configured()
callback.
Add documentation and a Coccinelle script to detect and prevent this
anti-pattern.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
It's customary for NOKPROBE_SYMBOL() macro usage to appear immediately
after a function's final closing brace, but checkpatch doesn't know that
yet. As a result, checkpatch --strict incorrectly flags this common
kernel pattern, e.g.,
CHECK: Please use a blank line after function/struct/union/enum declarations
33: FILE: arch/riscv/kernel/traps.c:273:
}
+NOKPROBE_SYMBOL(probe_single_step_handler);
Fix by adding NOKPROBE_SYMBOL to the whitelist of patterns that are
cleared to appear immediately after functions.
Link: https://lore.kernel.org/[email protected]
Signed-off-by: Paul Walmsley <[email protected]>
Acked-by: Joe Perches <[email protected]>
Cc: Nam Cao <[email protected]>
Cc: Jisheng Zhang <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Auto-add `type OwnerModule: ::kernel::ModuleMetadata;` as a required
associated type on the trait side if not already defined, and
auto-insert `type OwnerModule = crate::LocalModule;` on the impl side
if not explicitly provided, eliminating the need to manually declare
and implement `OwnerModule` in every vtable trait and impl.
Assisted-by: opencode:glm-5.2
Reviewed-by: Andreas Hindborg <[email protected]>
Suggested-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Reviewed-by: Gary Guo <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Signed-off-by: Alvin Sun <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ Fixed `rusttest` by adding a dummy `LocalModule`. Removed interim
`#[allow(dead_code)]`. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
Add a `LocalModule` struct with a null-pointer `ModuleMetadata` impl
in the doctest harness, so that `crate::LocalModule` (auto-inserted
by `#[vtable]`) resolves correctly when there is no `module!` macro.
Assisted-by: opencode:glm-5.2
Reviewed-by: Andreas Hindborg <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Signed-off-by: Alvin Sun <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ Fixed `clippy::undocumented_unsafe_blocks` lint by wrapping with
a block. Added interim `#[allow(dead_code)]`. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
Add a KUnit test suite for the AES-GCM library API.
It consists of:
- All the shared test cases from aead-test-template.h. These include
extensive consistency tests, a "Monte-Carlo test", and a benchmark.
- Tests against hardcoded AES-GCM test vectors from external sources.
Reviewed-by: Ard Biesheuvel <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Eric Biggers <[email protected]>
Add a KUnit test suite for the AES-CCM library API.
It consists of:
- All the shared test cases from aead-test-template.h. These include
extensive consistency tests, a "Monte-Carlo test", and a benchmark.
- Tests against hardcoded AES-CCM test vectors from external sources.
- Tests for CCM-specific message length validation.
To generate the expected aes_ccm_monte_carlo_checksum[] value, add a
script gen-aead-testvecs.py which computes it using python-cryptography.
Reviewed-by: Ard Biesheuvel <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Eric Biggers <[email protected]>
Upcoming changes will wire up architecture-optimized implementations of
GCM and CCM. FIPS labs can consider such designs to meet the threshold
for separate self-tests to be needed.
Therefore, add FIPS self-tests for encryption and decryption in these
modes.
Reviewed-by: Ard Biesheuvel <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Eric Biggers <[email protected]>
Upcoming changes will wire up architecture-optimized implementations of
ECB, CBC, CBC-CTS, CTR, and XTS. FIPS labs can consider such designs to
meet the threshold for separate self-tests to be needed.
The inverse direction of the block cipher also needs to be exercised,
which the existing CMAC self-test doesn't do.
Therefore, add FIPS self-tests for encryption and decryption in these
modes as well as the "bare" AES.
Reviewed-by: Ard Biesheuvel <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Eric Biggers <[email protected]>
In preparation for adding FIPS self-tests for AES encryption modes,
split fips.h into separate files for the AES and SHA test vectors.
They are still generated by the same script, but this keeps things a bit
more organized.
Reviewed-by: Ard Biesheuvel <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Eric Biggers <[email protected]>
Emit the bpf_kfunc decl tag for every discovered kfunc, and bpf_fastcall
for kfuncs flagged KF_FASTCALL. These were previously produced by pahole
under --btf_features=decl_tag_kfuncs.
resolve_btfids now discovers kfuncs from the BTF ID sets [1] and
becomes the source of truth for their annotations.
Drop decl_tag_kfuncs pahole feature flag from scripts/Makefile.btf
[1] https://lore.kernel.org/all/[email protected]/
Signed-off-by: Ihor Solodrai <[email protected]>
Acked-by: Eduard Zingerman <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Eduard Zingerman <[email protected]>
For kfuncs flagged with KF_ARENA_RET, KF_ARENA_ARG1 or KF_ARENA_ARG2,
the address_space(1) attribute (a type tag with kflag=1) must be
emitted for the corresponding type in BTF. This was previously done by
pahole via the "attributes" BTF feature [1].
Implement the emission of the arena attributes in resolve_btfids: for
flagged kfuncs create a new function prototype with updated BTF types.
The original proto may be shared with sibling FUNCs, so it is not
modified in place.
Emission is unconditional: kbuild controls the pahole flags, so the
input BTF is expected to not have these attributes. Invalid
declarations are reported as errors.
Drop the "attributes" pahole feature from scripts/Makefile.btf
resolve_btfids now emits them for all supported pahole versions.
[1] https://lore.kernel.org/dwarves/[email protected]/
Signed-off-by: Ihor Solodrai <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Eduard Zingerman <[email protected]>
The linker script scripts/module.lds.S contains an unused DISCARD_EH_FRAME
definition introduced by commit 68c76ad4a9 ("arm64: unwind: add
asynchronous unwind tables to kernel and modules").
As shown in an earlier version of that patch [1], DISCARD_EH_FRAME was
meant to be used by SANITIZER_DISCARDS in the same file, as follows:
-# define SANITIZER_DISCARDS *(.eh_frame)
+# define SANITIZER_DISCARDS DISCARD_EH_FRAME
However, in the meantime, SANITIZER_DISCARDS was removed entirely from
module.lds.S by commit 8924560094 ("cfi: Switch to -fsanitize=kcfi").
Eventually, the mentioned commit 68c76ad4a9 only added the new
DISCARD_EH_FRAME definition to this file without actually using it.
The file include/asm-generic/vmlinux.lds.h contains a similar
DISCARD_EH_FRAME definition for vmlinux to discard .eh_frame sections that
may be present when CONFIG_GCOV_KERNEL, CONFIG_KASAN_GENERIC or
CONFIG_KCSAN is enabled. Testing these options on arm64 with LLVM 19.1 did
not show any unexpected .eh_frame sections in modules.
Remove the unused DISCARD_EH_FRAME definition from scripts/module.lds.S.
Link: https://lore.kernel.org/linux-arm-kernel/[email protected]/ [1]
Reviewed-by: Sami Tolvanen <[email protected]>
Signed-off-by: Petr Pavlu <[email protected]>
There is a new format for the 'Assisted-by:' tag. Change checkpatch.pl
to just check that it has a value rather than testing for a specific
format.
Assisted-by: LLM
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>
Message-ID: <[email protected]>
It can happen that symbol sizes within .tmp_vmlinux1.kallsyms.o and
.tmp_vmlinux2.kallsyms.o differ, without affecting file size on disk
because of section alignment and/or padding emitted by the assembler.
link-vmlinux.sh doesn't detect this case currently and keeps using
.tmp_vmlinux2.kallsyms.o to link the final vmlinux. Due to the
different symbol sizes, other symbols are shifted within the final
image compared to .tmp_vmlinux2, and the final comparison of System.map
against "${kallsyms_sysmap}" fails with the message:
Inconsistent kallsyms data
Try "make KALLSYMS_EXTRA_PASS=1" as a workaround
This can happen in particular if the linker emits additional symbols
that might have different names between our (re-)linking steps, e.g.
because those names depend on the virtual address of the symbol. Linker
stubs for ARM errata work-arounds are one such case.
These changed symbol names can cause the output of the token
compression of kallsyms.c to change due to the changed symbol substring
count, which in turn can change the size of the kallsyms_names symbol
itself, causing the potential shift of subsequent symbol addresses in
.tmp_vmlinux2.kallsyms.o and therefore the final image.
Update link-vmlinux.sh to not rely on file size of
.tmp_vmlinux?.kallsyms.o alone but to also consider symbol offsets
within to resolve this, and do a third pass if required.
Signed-off-by: André Draszik <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
Signed-off-by: Nicolas Schier <[email protected]>
Add symbol size for kallsyms symbols that can change size so that sizes
can be determined easily without having to manually calculate them
when inspecting the object files (.tmp_vmlinux?.kallsyms.o or
.tmp_vmlinux?). Without, the assembler records the symbol size as 0.
This is primarily useful as a debugging aid in case of linker errors as
part of link-vmlinux.sh, and because symbol size doesn't have to align
with the offset to the next symbol due to padding/alignment.
Signed-off-by: André Draszik <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
Signed-off-by: Nicolas Schier <[email protected]>
The use of in-place editing was removed by commit 83e8b90e1d
("scripts/config: use sed's POSIX interface").
Before that, the script used bare `-i' to skip creating a backup file.
In fact, major sed implementations have supported `-i' for over a
decade. It's really doubtful if anyone would still build Linux on a Unix
system without it. The issue is more about how we use it:
FreeBSD and macOS disallow bare `-i'. To skip creating a backup, an
empty string ("zero-length extension") must be passed as a separate
argument following `-i'.
GNU and other BSDs accept bare `-i' to skip creating a backup, but
disallow passing a zero-length extension.
That being said, when thinking about it optimistically, using `-i' is
portable as long as a backup is created.
Use in-place editing (-i) in a portable manner by creating a backup file
with a .swp extension (the same name as the current temporary file). The
backup file will be deleted on exit.
A rough benchmark with ~1000 editions showed a 14.4% speedup (5.27s =>
4.51s, GNU sed). The FreeBSD sed showed a similar speedup.
Reviewed-by: Nicolas Schier <[email protected]>
Signed-off-by: Rong Zhang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Nicolas Schier <[email protected]>
The use of Extended Regular Expressions was removed by commit
83e8b90e1d ("scripts/config: use sed's POSIX interface").
Before that, the script used `-r' to enable ERE, which is indeed
non-portable. However, POSIX.1-2024 [1][2] has accepted `-E' as a
standard option to use ERE for matching, and major sed implementations
(GNU, FreeBSD, OpenBSD, NetBSD, macOS) have supported `-E' for over two
decades, so it makes no sense to use Basic Regular Expressions any more.
Switch to ERE to get rid of chained calls to sed. A rough benchmark with
~1000 editions showed a 40.0% speedup (8.78s => 5.27s, GNU sed). The
FreeBSD sed showed a similar speedup.
Link: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html [1]
Link: https://austingroupbugs.net/view.php?id=528 [2]
Reviewed-by: Nicolas Schier <[email protected]>
Signed-off-by: Rong Zhang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Nicolas Schier <[email protected]>
The allocation for elf info symsearch and hdr from parse_elf() haven't
been released when return because of modname didn't have suffix ".o".
And it seems like the suffix ".o" check did not depends on parse_elf()
to succeed first. So, move the suffix ".o" check before checking
parse_elf() result to prevent resource leak when the modname didn't have
suffix ".o" and return early.
This is reported by Coverity Scan as "Resource leak".
Fixes: 8c9ce89c5b ("modpost: simplify mod->name allocation")
Signed-off-by: Robertus Diawan Chris <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Nicolas Schier <[email protected]>
When a non-interactive 'make oldconfig' or 'syncconfig' meets a new int
or hex symbol whose default cannot be applied, conf_string() reads a
value from stdin. At end of file fgets() returns NULL, no value is set
and the loop asks again. The result is an endless loop which fills the
output until it exhausts memory, rather than a clean failure.
Detect this in conf_string(): if the value cannot be set and stdin is at
end of file, stop with an error that names the symbol.
Note that a symbol with no default doesn't trigger this, since
sym_calc_value() falls back to 0, which is accepted at end of file. The
loop is triggered by a broken Kconfig file, with a default whose text
fails sym_string_valid().
Such mistakes do creep in from time to time and are hard to debug, since
the build fills the log with repeated prompts instead of pointing at the
offending symbol. Some bad defaults draw a parse-time warning, but
menu_validate_number() accepts a reference to any int or hex symbol, so
a cross-type reference loops with no warning at all. For example, "0xff"
is not a valid int value:
config HEXSYM
hex
default 0xff
config VAL
int "Value"
default HEXSYM
Interactive use is unaffected, since feof() only becomes true once a
read actually hits end of file: an invalid answer at a terminal still
re-prompts, while Ctrl-D at such a prompt exits with the error instead
of looping. bool and tristate symbols and choices already accept the
default on an empty line, so they still take their defaults in a
non-interactive build.
Tested with int and hex symbols carrying such defaults: with empty
stdin, the code without this change produces around 190MB of repeated
prompts within two seconds, while with the change it exits 1 naming the
symbol. Piped and interactive (pty) sessions still re-prompt on an
invalid answer and then accept a valid one. A new string symbol with no
default still takes the empty string at end of file, since any text is
valid for a string.
Signed-off-by: Simon Glass <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Nicolas Schier <[email protected]>
When executing the command `make cscope`, the `cscope.files` file
generated by it includes only filenames with the extensions *.h, *.c,
*.S and not includes filenames with *.rs extensions.
To fix this, modify the functions `find_arch_sources()`,
`find_arch_include_sources()`, `find_include_sources()`, and
`find_other_sources()` so that they can accept an unlimited number of
filename patterns as parameters for the search. Add the
`setup_name_pattern()` function to convert these filename pattern
parameters into a list of parameters that can be passed to the `find`
utility via the new `pattern` variable.
Signed-off-by: Sergei Litvin <[email protected]>
Acked-by: Miguel Ojeda <[email protected]>
Tested-by: Nicolas Schier <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
Link: https://patch.msgid.link/[email protected]
[nsc: cleaned-up commit message line breaks and removed cc trailers]
Signed-off-by: Nicolas Schier <[email protected]>
When executing the command `make COMPILED_SOURCE=1 cscope`, the resulting
`cscope.files` file contains filenames with the extensions *.rlib, *.rmeta,
and *.so.
To fix this, modify the regular expression in the `all_compiled_sources()`
function so that only files with the extensions *.h, *.c, *.S, and *.rs are
accepted.
The issue has been introduced by commit 4f491bb6ea ("scripts/tags.sh:
collect compiled source precisely") which implemented the parsing of
compiled sources from *.cmd files instead of using the "find" command.
Fixes: 4f491bb6ea ("scripts/tags.sh: collect compiled source precisely")
Signed-off-by: Sergei Litvin <[email protected]>
Acked-by: Miguel Ojeda <[email protected]>
Tested-by: Nicolas Schier <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
Link: https://patch.msgid.link/[email protected]
[nsc: cleaned-up commit message line breaks and removed cc trailers]
Signed-off-by: Nicolas Schier <[email protected]>
A previous patch to headers_install.sh normalized the usage of
__ASSEMBLER__ to __ASSEMBLY__ in the UAPI headers due to two reasons:
1) There was the concern that the UAPI headers might be used with
non-GCC-compatible compilers, which do not define __ASSEMBLER__
automatically.
But other C compilers like PCC (see
https://github.com/IanHarvey/pcc/blob/cvs2git/2018.09.20/cc/cc/cc.1#L405)
and Tiny-C (see https://repo.or.cz/tinycc.git/commitdiff/a25325e9be13e52a),
are defining __ASSEMBLER__ for compiling assembler files, too, so using
it in UAPI header files should really be fine.
2) During the migration phase, the UAPI headers will use a mix of *both*
__ASSEMBLY__ and __ASSEMBLER__ at the same time, which is ugly and
inconsistent.
That's true. But since we already shipped a couple of kernel versions
that used __ASSEMBLER__ in the UAPI headers for certain architectures,
we might now break user space programs that have been developed with
these kernel versions if we switch back to __ASSEMBLY__.
Thus let's better always use the macro that is defined by the compilers
and standardize on __ASSEMBLER__ instead of __ASSEMBLY__ in all of the
UAPI header files now.
Suggested-by: Thomas Weißschuh <[email protected]>
Link: https://lore.kernel.org/all/[email protected]/
Reviewed-by: Nicolas Schier <[email protected]>
Tested-by: Nicolas Schier <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Nicolas Schier <[email protected]>
The USB and PCI device bindings define some compatible patterns based on
device IDs that use the comma to separate vendor and product IDs.
These prefix patterns include:
- ^usb(if)?[0-9a-f]{1,4},
- ^pci[0-9a-f]{2,4},
- ^pciclass,
These are not real vendor prefixes. Don't emit warnings for them.
Instead just skip over the DT compatible check altogether, and leave the
real check to the DT validator. This avoids false positive warnings about
undocumented DT vendor prefixes and compatibles.
Note that the script mostly only checks the first compatible string of
each node, as it processes the source file line-by-line, and the check
only matches on the line with 'compatible = "..."'. Otherwise there would
be more warnings from arch/mips/boot/dts/loongson/ls7a-pch.dtsi since that
file also includes compatibles like "pciclass0c0310" and "pciclass0c03"
which are not accepted either. "pci0014,7a24.0" is not valid either, but
this patch leaves the real check to the DT validator.
Link: https://lore.kernel.org/[email protected]
Signed-off-by: Chen-Yu Tsai <[email protected]>
Reviewed-by: Brian Norris <[email protected]>
Tested-by: Brian Norris <[email protected]>
Cc: Andy Whitcroft <[email protected]>
Cc: Dwaipayan Ray <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Lukas Bulwahn <[email protected]>
Cc: Rob Herring <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Starting with LLVM 22, `clang_getTypeDeclaration()` may return a forward
declaration instead of the type definition. This made `bindgen` generate
opaque types [1][2], which in turn made us fail with e.g.
error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`
--> rust/kernel/module_param.rs:78:46
|
78 | let container = unsafe { &*((*param).__bindgen_anon_1.arg.cast::<SetOnce<T>>()) };
| ^^^^^^^^^^^^^^^^ unknown field
|
= note: available field is: `_address`
This was fixed in `bindgen` 0.72.1 [3].
In order to clarify what is going on and avoid confusion [4][5], add
a warning to `rust_is_available.sh` about it when the versions match,
similar to past warnings like the one removed in:
commit ae64324ad5 ("rust: rust_is_available: remove warning for `bindgen` < 0.69.5 && libclang >= 19.1")
In addition, even if the versions match, check if the issue appears to
not reproduce with the given binaries, to avoid a warning in such a case.
Finally, include tests.
[ Nathan, in parallel, updated the instructions of the LLVM+Rust
kernel.org toolchains [6] so that `--version` is not passed to
`cargo` for `bindgen`, and thus the latest `bindgen` is installed
by default, which should help to avoid some of these situations.
Thanks!
- Miguel ]
Cc: [email protected] # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Link: https://github.com/rust-lang/rust-bindgen/issues/3264 [1]
Link: https://github.com/Rust-for-Linux/linux/issues/353 [2] # "Missing fields in nested class with LLVM 22."
Link: https://github.com/rust-lang/rust-bindgen/pull/3278 [3]
Reported-by: Burak Emir <[email protected]>
Link: https://github.com/Rust-for-Linux/linux/issues/1247 [4]
Link: https://lore.kernel.org/rust-for-linux/CABwQupNfMAJOGqRM9ke6tj4f53dCCsBDKU7Vp+zf8mwk7bqt8Q@mail.gmail.com/ [5]
Link: https://mirrors.edge.kernel.org/pub/tools/llvm/rust/ [6]
Tested-by: Burak Emir <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
`command -v` behaves differently on `dash` vs. `bash` when faced with
a file without the execute bit.
Thus, for the non-executable `rustc` and `bindgen` tests, support both
possible outputs that the script currently gives.
This makes the test script clean on distributions like Fedora.
Reviewed-by: Onur Özkan <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ Added custom assertion message as suggested. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
find_sympos() calculates a sympos used by livepatch to disambiguate
duplicately-named symbols. For function symbols, there's a hack which
counts .text.unlikely symbols before other .text symbols, matching the
linker script's section ordering.
Not only is the hack fragile, data symbols can have the same problem.
So for example, adding a reference to pwq_cache in
ep_unregister_pollwait() can trigger a corrupt sympos and a relocation
to the wrong pwq_cache symbol in the livepatch module, resulting in a
crash or undefined behavior.
Remove the existing hack in favor of a fully deterministic solution,
using the new .klp.symid table to derive the symbol-to-id mapping from
the original vmlinux.o and the id-to-address mapping from the
corresponding vmlinux, which can then be used to determine the exact
sympos associated with the original vmlinux.
Modules don't need any special treatment: the .ko has the same
section/symbol ordering as the original whole-archive symbol table.
Fixes: dd590d4d57 ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Reported-by: Ben Procknow <[email protected]>
Reported-by: Joe Lawrence <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/[email protected]
Link: https://lore.kernel.org/[email protected]
Link: https://patch.msgid.link/919785e3bf2245db02ff6391e735d9cb139170b1.1785727106.git.jpoimboe@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 <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Cc: [email protected]
Link: https://patch.msgid.link/64d50f077b569f47883c015cdb7079edb068efe8.1785727106.git.jpoimboe@kernel.org
parse_inputs_from_commands() only caught CmdParsingError and IndexError
when dispatching to command parsers, but several parsers call
shlex.split() internally, which raises ValueError on malformed shell
quoting (e.g. an unterminated quote). This exception was not caught,
so a single malformed build command would abort SBOM generation
entirely, even with fail_on_unknown_build_command=False, defeating the
purpose of tolerant mode.
The issue was found while reviewing the exception handling around the
saved-command parser after running its existing tests. It can be
reproduced with:
parse_inputs_from_commands('gcc "unterminated',
fail_on_unknown_build_command=False)
Catch ValueError alongside CmdParsingError and IndexError so such
commands are logged as a warning/error and skipped instead of aborting
the whole run.
Add tests covering malformed shell quoting and a missing positional
argument.
Signed-off-by: Carlos Sampaio Ribeiro <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
After switching to the kernel's default package scripts for our local
kernel RPM builds, we noticed that module BTF entries were missing:
$ ls /sys/kernel/btf/
vmlinux <<<< only vmlinux, no module BTF
Root cause: find-debuginfo.sh (from the debugedit package) prefers
eu-strip over strip when elfutils is installed, which is the common
case on RHEL 9. eu-strip removes non-allocated ELF sections, including
the .BTF section that contains BPF Type Format information for kernel
modules. Without .BTF, BPF tools (bpftool, bcc, bpftrace) cannot resolve
kernel types at runtime, and /sys/kernel/btf/<module> entries are not
created when modules are loaded.
Additionally, since commit 8646db2389 ("libbpf,bpf: Share BTF
relocate-related code with kernel"), modules contain a .BTF.base section
that maps distilled type IDs to vmlinux types. If .BTF.base is stripped,
btf_parse_module() falls back to vmlinux BTF directly, causing type ID
mismatches and rejecting the module's BTF entirely.
Fix by passing --keep-section .BTF and --keep-section .BTF.base via
_find_debuginfo_opts, which adds -K .BTF and -K .BTF.base to the
eu-strip/strip command, preserving both sections while allowing normal
debuginfo extraction to proceed.
After this change, all module BTF files are properly generated:
$ ls /sys/kernel/btf/
aesni_intel drm i2c_i801 mfd_core
ahci drm_client_lib i2c_mux net_failover
backlight drm_kms_helper i2c_smbus pcspkr
ccp drm_shmem_helper input_leds qemu_fw_cfg
dm_log failover intel_rapl_common sch_fq_codel
dm_mirror fat intel_rapl_msr serio_raw
dm_mod fuse irqbypass sunrpc
dm_region_hash gf128mul iTCO_wdt vfat
virtio_balloon virtio_console virtio_dma_buf virtio_gpu
virtio_net virtio_rng virtio_blk vmlinux
xfs
Suggested-by: Nathan Chancellor <[email protected]>
Signed-off-by: Yafang Shao <[email protected]>
Cc: Alan Maguire <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Nathan Chancellor <[email protected]>
The last_migrate_reason field uses -1 as a sentinel value to mean "no
migration has happened". Replace the four bare -1 occurrences by adding a
proper MR_NEVER member to enum migrate_reason, defining a corresponding
"never_migrated" string in the MIGRATE_REASON trace macro, and updating
the GDB page_owner script to use MR_NEVER instead of the hardcoded -1 so
that lx-dump-page-owner does not incorrectly report unmigrated pages as
migrated.
No functional change.
Link: https://lore.kernel.org/[email protected]
Signed-off-by: Ye Liu <[email protected]>
Reviewed-by: Zi Yan <[email protected]>
Reviewed-by: Vlastimil Babka (SUSE) <[email protected]>
Cc: Brendan Jackman <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Lorenzo Stoakes <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Suren Baghdasaryan <[email protected]>
Cc: David Hildenbrand (Arm) <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Wire up the fchroot() system call as number 472 on (nearly) all
architectures and sync the mirrored copies of the syscall tables and
the asm-generic unistd.h under tools/.
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Christian Brauner (Amutable) <[email protected]>
Script judges the indentation however always suggests it is the first
line which is wrong, e.g.:
sigmastar/mstar-infinity2m.dtsi:1: [indent-unit-dts] indent unit must be 1 tab in DTS, got '\t\t'
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rob Herring (Arm) <[email protected]>
dt-check-style was not properly handling DTC directives (starting with
'/', e.g. /dts-v1/ or /include/), thus a few DTS files had false
positive like:
apm/apm-merlin.dts:1: [indent-unit-dts] indent unit must be 1 tab in DTS, got '\t\t'
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rob Herring (Arm) <[email protected]>
A few nodes do have "device_type" property which is mostly, but not always,
the first property in a device node, when applicable. Adjust the DTS
coding style rules to actually expect the device_type first and improve
the dt-check-style to handle this correctly.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rob Herring (Arm) <[email protected]>
Individual rules behave differently depending whether they handle
bindings (YAML) or DTS, but the code was focusing on type of indentation
(spaces vs tabs). That indentation is actually irrelevant in some
rules, so differentiate based on file type. This will be more relevant
in the future when more rules act differently on DTS, than on bindings.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rob Herring (Arm) <[email protected]>
DTS often have spaces after tabs in indentation for aligning continued
lines of comments or list properties, thus allow such cases to avoid
many false positives. What we can easily detect is a space followed by
tab or too many spaces (more than alignment).
OTOH, DTS example in YAML files does not have tabs at all and there is
already rule for that, thus there is no point to check for mixed
indentation there.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rob Herring (Arm) <[email protected]>
DTS in the bindings (example in a YAML file) does not have tabs at all,
but regular DTS do, therefore entire check check_tab_in_dts() has
confusing name and should apply only to YAML files.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rob Herring (Arm) <[email protected]>
Krzysztof Kozlowski