Commit 454e00cf8e ("kbuild: avoid re-running compiler and linker
probes") moved many cc-option calls from the main Makefile into Kconfig.
In the process, code such as
ifdef CONFIG_CC_IS_GCC
KBUILD_CFLAGS += $(call cc-option,-foo)
endif
was converted into Kconfig as
config CC_OPT_FOO
def_string "$(cc-option-str,-foo)" if CC_IS_GCC
The 'if CC_IS_GCC' is generally unnecessary because it does not prevent
the cc-option-str call from running (which is the primary reason the
ifdef guards exists in the Makefile), as cc-option-str and the like are
run before Kconfig even parses the dependency. It only impacts the
symbol's visibility, which does not really matter in the general case,
so remove these dependencies.
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://patch.msgid.link/20261007-scripts-kconfig-toolchain-improvements-v1-1-1e524178da11@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
The gzip step of a kernel build is very lengthy, especially for larger
builds such as allmodconfig.
gzip itself cannot be run in parallel, however an alternative tool exists
that can, providing the same feature set as gzip itself - pigz - which
works as a drop-in replacement.
On a 128-core Threadripper, gzip -9 of a 36 MiB x86-64 vmlinux.bin takes
1.6s, and with pigz it takes 0.09s, so the performance increase is
significant.
Therefore introduce the KPGZIP build variable which specifies the
compressor to use for the kernel image and default it to pigz if available,
or KGZIP otherwise (which itself defaults to gzip).
Modules, packaging and the embedded kernel configuration (CONFIG_IKCONFIG)
continue to use KGZIP which defaults to a single-threaded gzip instance.
Module compression is run in parallel by make, so pigz offers no benefit
there, packaging sits outside the build and the embedded configuration is
too small to matter.
pigz is executed using scripts/jobserver-exec, which reserves the job slots
make has free - necessary, as otherwise pigz would just grab unbounded
CPUs.
The kernel image compression step is always performed at the end of the
build so should typically have all job slots available.
pigz always provides byte-for-byte identical output across runs regardless
of thread count, but pigz and gzip are not guaranteed to generate the same
binary output, so reproducible builds must use the same tools consistently.
Also update Documentation/kbuild/kbuild.rst to describe KPGZIP and
Documentation/process/changes.rst to list the optional pigz dependency.
While there, add entries for the other compressor programs.
Finally, update scripts/ver_linux to include the pigz version there.
Every x86 build ends with the compression of vmlinux.bin, 36MB for
defconfig and over 200MB for allmodconfig, no-op builds are unchanged.
Whole build, 128-thread Threadripper 9980X, best of N runs:
before after delta
-------------------------------
x86 defconfig, touch mm/vma.c, gcc 7.7s 6.0s -1.7s (-22%)
x86 defconfig, touch mm/vma.c, clang 6.9s 5.4s -1.5s (-21%)
x86 defconfig, clean, gcc 28.2s 26.3s -1.8s (-6%)
x86 defconfig, clean, clang 28.7s 27.2s -1.5s (-5%)
x86 allmodconfig, touch mm/vma.c, gcc 23.7s 15.4s -8.3s (-35%)
x86 allmodconfig, touch mm/vma.c, clang 22.5s 15.6s -7.0s (-31%)
x86 allmodconfig, clean, gcc 294.1s 278.6s -15.5s (-5%)
x86 allmodconfig, clean, clang 283.9s 266.8s -17.1s (-6%)
Suggested-by: Kees Cook <kees@kernel.org>
Link: https://zlib.net/pigz/
Assisted-by: LLM
Reviewed-by: Manuel Ebner <manuelebnerli@mailbox.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Link: https://patch.msgid.link/20260923-build-speedup-v4-22-73128809a4a4@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Each kernel make invocation begins with ~30 compiler and linker runs each
of which performs duplicate probe for a number of compiler and linker
options.
This is useless work - the compiler and its version is known, so use these
to determine which options are available, once.
Using the newly introduced cc-option-str, track the result of each probe in
CC_OPT_*, LD_OPT_* variables and have Makefile's simply append the symbol.
Some care has to be taken around negative options, i.e. -Wno-xxx, as gcc
accepts an unknown -Wno- without complaint and only complains later, so
instead probe the positive form for these cases.
Use CC_HAS_* For those probes that gate a Makefile conditional rather than
a simple option, as per the established pattern for this.
This change avoids a subtle issue with ppc32 (big endian) - clang doesn't
accept -fno-stack-clash-protection on this sub-target, so keep this option
in the Makefile.
With gcc and clang, defconfig and allmodconfig, the recorded command
lines are unchanged, a build with nothing to do rebuilds nothing and W=1
continues to function correctly.
Doing this improves all builds, but has a particularly positive impact on
no-op builds (builds where nothing has changed).
Whole build, 128-thread Threadripper 9980X, best of N runs:
before after delta
-------------------------------
x86 defconfig, no-op make, gcc 0.78s 0.60s -0.18s (-23%)
x86 defconfig, no-op make, clang 0.94s 0.66s -0.28s (-30%)
x86 defconfig, touch mm/vma.c, gcc 8.6s 8.5s -0.16s (-2%)
x86 defconfig, touch mm/vma.c, clang 8.0s 7.7s -0.24s (-3%)
x86 defconfig, clean, clang 29.8s 29.4s -0.37s (-1%)
x86 allmodconfig, no-op make, gcc 12.9s 12.7s -0.23s (-2%)
x86 allmodconfig, no-op make, clang 14.2s 13.9s -0.29s (-2%)
x86 allmodconfig, touch mm/vma.c, clang 32.2s 31.9s -0.30s (-1%)
Assisted-by: LLM
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Link: https://patch.msgid.link/20260923-build-speedup-v4-12-73128809a4a4@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
init/Kconfig opens with two hundred lines identifying the compiler,
assembler, linker and rustc and probing which options they support, none of
it to do with init.
Move them into their own file, sourced from the top of init/Kconfig, so
that the next commit can add to them without growing init/Kconfig further.
Also update MAINTAINERS to put the new file in the KCONFIG entry.
No functional change intended.
Assisted-by: LLM
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Link: https://patch.msgid.link/20260923-build-speedup-v4-11-73128809a4a4@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
mksysmap is a sed script consisting of 30 patterns which link-vmlinux.sh
uses to generate *.syms files, and which kallsyms is then called against to
generate *.kallsyms files, with the final vmlinux build ultimately
generating System.map.
For an x86-64 allmodconfig build, this involves three nm runs over a 250
MiB file and half a million lines written and read each time - 0.5s per
pass for llvm-nm, and 0.2s for GNU nm, with parsing on top of that.
This is unnecessary, instead have kallsyms simply read the ELF file
directly making use of the existing elf-parse library in scripts/.
This changes kallsyms such that its input is no longer the output from nm,
but rather an ELF file.
However, if the input file is empty, it outputs an empty table, which
retains the same behaviour on first pass that the build system expects.
System.map is byte-identical to nm | mksysmap for GNU nm and llvm-nm on
two x86 configurations each, and for llvm-nm on arm64, arm, s390 and
loongarch defconfigs, so are the kallsyms tables of every pass.
Relinking vmlinux, link steps included:
before after
allmodconfig clang 9.1s 7.9s
allmodconfig gcc 7.8s 7.6s
defconfig clang 3.7s 3.0s
defconfig gcc 3.5s 3.4s
Whole build, 128-thread Threadripper 9980X, best of N runs:
before after delta
-------------------------------
x86 defconfig, touch mm/vma.c, gcc 9.1s 8.6s -0.43s (-5%)
x86 defconfig, touch mm/vma.c, clang 9.0s 8.0s -1.1s (-12%)
x86 defconfig, clean, gcc 29.5s 28.9s -0.64s (-2%)
x86 defconfig, clean, clang 31.2s 29.8s -1.4s (-5%)
x86 allmodconfig, touch mm/vma.c, gcc 35.8s 35.0s -0.77s (-2%)
x86 allmodconfig, touch mm/vma.c, clang 35.8s 33.7s -2.0s (-6%)
Assisted-by: LLM
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Link: https://patch.msgid.link/20260923-build-speedup-v4-8-73128809a4a4@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Extend elf-parse to be able to read the symbol table of vmlinux in
kallsyms.
This requires the ability to open ELF files in read-only mode, so provide
elf_map_ro() to do so.
It also requires accessors for section flags and symbol bindings, so
provide these via shdr_flags() and sym_bind().
It's useful to be able to open an ELF file, map it, and then have easy
access to its section headers, names and symbol table, so introduce struct
elf_file to store this.
In order to obtain this data also provide elf_open_ro() and elf_close().
Also, check for the file being an ELF file first in elf_parse(). This is
the logical thing to check for first, but additionally prevents kallsyms
from having to check this it self.
Assisted-by: LLM
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Link: https://patch.msgid.link/20260923-build-speedup-v4-7-73128809a4a4@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
A kernel build consists of more than one linking pass on vmlinux.o and
vmlinux, at minimum two, and with CONFIG_KALLSYMS and BTF enabled on x86-64
for example there are 5 such stages.
For architectures that build their own relocation tables (x86, riscv, mips,
s390), vmlinux is linked with the --emit-relocs parameter specified.
However, this is only required on the final vmlinux link.
Symbol tables of trial links preceding it don't need it because they
already check that System.map matches kallsyms symbols on each build.
GNU ld is slow at emitting relocation tables, so this results in a
reduction in build time.
Whole build, 128-thread Threadripper 9980X, best of N runs:
before after delta
-------------------------------
x86 defconfig, touch mm/vma.c, gcc 9.5s 9.1s -0.42s (-4%)
x86 defconfig, clean, gcc 30.1s 29.5s -0.59s (-2%)
x86 allmodconfig, touch mm/vma.c, gcc 37.2s 35.8s -1.4s (-4%)
Note that this has little impact on LLVM ld which performs this operation
more efficiently.
Assisted-by: LLM
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Link: https://patch.msgid.link/20260923-build-speedup-v4-6-73128809a4a4@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Unless instructed otherwise, nm sorts by name.
There are places where this is unnecessary - an invocation from
scripts/sorttable every vmlinux link, scripts/check-function-names.sh run
after every vmlinux.o link, and the x86 VOFFSET and ZOFFSET listings
between vmlinux and bzImage.
Both GNU nm and llvm-nm accept the same '-p' parameter to disable sorting
in these instances, so use that to prevent this unnecessary work.
Each nm run on its own, x86-64, median of 5:
GNU nm 2.47 llvm-nm 22
before after delta before after delta
defconfig
sorttable, nm -S vmlinux 0.080s 0.039s -0.041s 0.265s 0.113s -0.152s
check-function-names.sh 0.072s 0.033s -0.039s 0.244s 0.102s -0.142s
VOFFSET 0.077s 0.034s -0.043s 0.261s 0.113s -0.148s
ZOFFSET 0.007s 0.005s -0.002s 0.005s 0.005s 0.000s
TOTAL -0.125s -0.442s
allmodconfig
sorttable, nm -S vmlinux 0.156s 0.063s -0.093s 0.539s 0.223s -0.316s
check-function-names.sh 0.149s 0.054s -0.095s 0.537s 0.217s -0.320s
VOFFSET 0.146s 0.052s -0.094s 0.524s 0.221s -0.303s
ZOFFSET 0.007s 0.005s -0.002s 0.006s 0.004s -0.002s
TOTAL -0.284s -0.941s
llvm-nm appears to be a lot slower than GNU nm, so these builds naturally
improve the most.
The four run one after another in the serial tail of every build that links
vmlinux so impact kernel builds directly.
In an allmodconfig the decompressor is built in parallel while the modules,
so only the two before the vmlinux link contribute to build time.
The build outputs remain unchanged.
Whole build, 128-thread Threadripper 9980X, best of N runs:
before after delta
---------------------------------
x86 defconfig, touch mm/vma.c, gcc 9.7s 9.5s -0.18s (-2%)
x86 defconfig, touch mm/vma.c, clang 9.3s 9.0s -0.27s (-3%)
x86 defconfig, clean, gcc 30.3s 30.1s -0.16s (-1%)
x86 defconfig, clean, clang 31.7s 31.2s -0.55s (-2%)
x86 allmodconfig, touch mm/vma.c, clang 36.4s 35.8s -0.67s (-2%)
Assisted-by: LLM
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Link: https://patch.msgid.link/20260923-build-speedup-v4-5-73128809a4a4@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
sorttable reads a list of functions from vmlinux, provided by the output of
nm, with the -S flag specified providing function sizes.
It does so using fscanf(fp, "%16s %16s %c %*s\n", ...) reading address,
size, type (a single character) and name.
However, nm outputs no size for a symbol which has none, meaning that it
misinterprets these entries - interpreting the type character as the size,
and, if the name is a single character, ignores the newline and swallows
the address of the next entry.
Size-less single character names exist (e.g. the assemblers' loop counters
left over as local absolute symbols):
0000000000000001 a i
000000000000000f a i
0000000000000050 a j
0000000000000052 a t
000000000000009f a i
0000000000000200 a i
sorttable is looking for functions and these are not that, and with nm's
output sorted, it just so happens to be that what's swallowed is never a
function.
However the next commit in this series stops sorting nm's output, so this
bug can results in function names being lost.
Fix the issue by using '%*[^\n]' in fscanf() rather than '%*s' such that
the scan cannot move past the newline.
Then, compare the address and size fields (which are always padded to the
same width if output by nm) - if they differ, then this is a misread, so
simply discard the entry.
It's fine to discard these, as sorttable's raison d'être is to discover
whether a call site is contained within a function and an empty function
can't contain anything.
Assisted-by: LLM
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Link: https://patch.msgid.link/20260923-build-speedup-v4-4-73128809a4a4@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
kallsyms generates an assembly file that consists mostly of .byte entries
containing compressed names, token strings and name-sorted sequence
numbers.
For an x86-64 build with 158k symbols that is a 37 MiB .S file which takes
0.57s to assemble each of the two to three times it is built over a kernel
build.
Each time it is generated it also takes kallsyms a similar amount of time
to output it.
Avoid this overhead by instead outputting this data as binary and importing
it into the assembly using the .incbin directive.
Tables that are wider than a byte remain part of the assembly to ensure
endianness and relative relocations are performed correctly.
With this change, the output assembly file shrinks from 37 MiB to 9.8 MiB,
with a 2.6 MiB binary data file alongside it, and the object remains
identical.
The generated binary file is deleted correctly on build clean along with
all other ephemeral data.
On an x86-64 system with CONFIG_KALLSYMS_ALL set:
before after delta
scripts/kallsyms 0.24s 0.18s 0.06s
assemble 0.57s 0.16s 0.41s
Per kallsyms invocation/assembly, for a total of 0.47s time saving upon
invocation.
An incremental build on the same system was reduced from 11.15s to 9.65s,
indicating a total of 1.5 seconds saved over the build.
The kallsyms runs and their assembly are on the serial tail of every build
that links vmlinux, no-op builds are unchanged.
Whole build, 128-thread Threadripper 9980X, best of N runs:
before after delta
-------------------------------
x86 defconfig, touch mm/vma.c, gcc 10.6s 9.7s -0.89s (-8%)
x86 defconfig, touch mm/vma.c, clang 10.5s 9.3s -1.2s (-11%)
x86 defconfig, clean, gcc 31.3s 30.3s -1.0s (-3%)
x86 defconfig, clean, clang 33.3s 31.7s -1.6s (-5%)
x86 allmodconfig, touch mm/vma.c, gcc 38.7s 37.2s -1.4s (-4%)
x86 allmodconfig, touch mm/vma.c, clang 39.1s 36.4s -2.6s (-7%)
Assisted-by: LLM
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Link: https://patch.msgid.link/20260923-build-speedup-v4-3-73128809a4a4@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
The kallsyms program compresses symbols by figuring out the most commonly
used substrings in all of the input symbols then uses special character
codes to represent them.
For instance, 0xf7 might end up representing "write_", then every single
symbol that contains "write_" can use 0xf7 as a shorthand and save 5 bytes
each time.
'Special' character codes are any byte value that is not used in any
symbol, either due to being an invalid character, or not being present in
any symbol (e.g. if no symbol contains 'z', then 'z' can be used as special
character).
It does this by first figuring out which special characters are available
in insert_real_symbols_in_table(), then iterating through every available
special character, counting how many times each pair of adjacent characters
appear in symbols in build_initial_token_table().
These adjacent pairs are known as 'tokens'.
Token counts are initially obtained by build_initial_token_table(), then
optimize_result() calls find_best_token() to determine the token that
appeared the most number of times and assigns it the next special
character.
Finally, optimize_result() calls compress_symbols() to replace every token
in every symbol with its special character, which updates token_profit[] as
it does so.
This process is repeated for each remaining available special character,
with tokens now perhaps containing previously assigned special
characters (e.g. if 'wr' was assigned 0x80, then the token representing
'wri' would be '\x80i').
This compresses that token by 50% in each symbol it appears in (two bytes
are now represented by one) and thus by repeatedly doing this kallsyms
obtains good symbol compression.
However, compress_symbols() is seriously inefficient - it iterates through
EVERY symbol for EVERY special character assignment, i.e. ~256 *
nr_symbols.
Modern x86-64 kernels, for instance, have ~158,000 symbols, so millions of
iterations are performed, most of which are entirely unnecessary (tokens
don't appear in most symbols).
In practice kallsyms spends half its runtime doing this, two or three times
per vmlinux link step.
Fix this by tracking which symbols each token appears in token_syms[], and
only compress symbols which actually need to be updated.
Each time a token is compressed that token can no longer appear in any
symbol, so that token_syms[] entry can be freed.
However new token_syms[] entries must be created for each new token
containing the assigned special character, but this is bounded by the
number of replacements in the symbol which is very small.
In testing on an x86-64 platform using clang, each kallsyms invocation
dropped from 0.59s to 0.33s with CONFIG_KALLSYMS_ALL set and from 0.38s to
0.22s without it set.
The data was carefully checked and verified to be byte-for-byte identical
for six symbol sets (two vmlinux passes, vmlinux.o, three userspace
binaries) with all option combinations.
As part of this change, additionally refactor the code to be a little
easier to follow.
kallsyms runs two or three times on the serial tail of every build that
links vmlinux, no-op builds do not link and are unchanged.
Whole build, 128-thread Threadripper 9980X, best of N runs:
before after delta
-------------------------------
x86 defconfig, touch mm/vma.c, gcc 11.1s 10.6s -0.53s (-5%)
x86 defconfig, touch mm/vma.c, clang 11.1s 10.5s -0.64s (-6%)
x86 defconfig, clean, gcc 32.3s 31.3s -1.0s (-3%)
x86 defconfig, clean, clang 34.2s 33.3s -0.89s (-3%)
x86 allmodconfig, touch mm/vma.c, gcc 39.7s 38.7s -1.0s (-3%)
x86 allmodconfig, touch mm/vma.c, clang 40.3s 39.1s -1.3s (-3%)
Assisted-by: LLM
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Link: https://patch.msgid.link/20260923-build-speedup-v4-2-73128809a4a4@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Commit 3e86e4d74c ("kbuild: keep .modinfo section in vmlinux.unstripped")
placed MODULE_INFO() strings in the .modinfo section in vmlinux.unstripped,
however it left the section allocatable, so it gets assigned an address and
on arm64, arm and riscv, the section is tagged as PT_LOAD.
This is useless as the data is ultimately stripped anyway.
Doing this results in a lot of unnecessary work - each pass copies the
whole file, 450 MiB with relocations for an x86 allmodconfig build and 250
MiB for an arm64 allmodconfig build.
This adds ~0.7s on the serial tail of every build for arm64 and ~0.2s for
x86 (the tail is single-threaded work done after parallel work has
finished).
Nothing requires .modinfo to exist at an address, so mark the output
section (INFO) so that it's not allocated and use --dump-section to extract
it as -O only emits allocated sections.
The dump doesn't pick up the arch's OBJCOPYFLAGS any longer as they should
not impact the output of this section.
Image, bzImage, System.map and modules.builtin.modinfo are unchanged and
the stripped vmlinux differs only in its program headers.
The objcopy passes are on the serial tail of every build that links
vmlinux, no-op builds are unchanged.
Whole build, 128-thread Threadripper 9980X, best of N runs:
before after delta
-------------------------------
x86 defconfig, touch mm/vma.c, gcc 11.2s 11.1s -0.15s (-1%)
x86 defconfig, touch mm/vma.c, clang 11.3s 11.1s -0.19s (-2%)
x86 defconfig, clean, gcc 32.5s 32.3s -0.16s (-1%)
x86 defconfig, clean, clang 34.5s 34.2s -0.26s (-1%)
x86 allmodconfig, touch mm/vma.c, gcc 40.1s 39.7s -0.44s (-1%)
Assisted-by: LLM
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Link: https://patch.msgid.link/20260923-build-speedup-v4-1-73128809a4a4@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Add the linker counterpart to $(cc-option-str), sharing a $(ld-probe)
with $(ld-option) the way the compiler macros share $(cc-probe). Like
$(cc-option-str), it can now be used as:
config LD_OPT_FOO
def_string "$(ld-option-str,--new-option,--old-option)"
An omitted fallback expands to the empty string.
Build tested ARCH=x86_64 defconfig with GCC 16.2.0, and checked against
GNU ld 2.47.
Assisted-by: LLM
Signed-off-by: Kees Cook <kees@kernel.org>
Tested-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Julian Braha <julianbraha@gmail.com>
Link: https://patch.msgid.link/20260919005929.4077729-3-kees@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
$(cc-option-bit) returns the flag it was given when the compiler accepts
it, and an empty string otherwise. It was originally only used
internally for machine bit flags, but it is generally useful[1].
Rename it to $(cc-option-str), which says what it returns rather than
what it was first used for, and extract the probe logic from the existing
$(cc-option) macro to reuse it. Additionally add support for an optional
fallback, much like the Kbuild cc-option macro. This can be used as:
config CC_OPT_FOO
def_string "$(cc-option-str,-fnew-option,-fold-option)"
If the fallback is omitted, it is just an empty string.
Build tested ARCH=x86_64 defconfig with GCC 16.2.0.
Assisted-by: LLM
Signed-off-by: Kees Cook <kees@kernel.org>
Tested-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Julian Braha <julianbraha@gmail.com>
Link: https://patch.msgid.link/20260919005929.4077729-2-kees@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Kconfig has offered "def_bool" and "def_tristate" as a shorthand for a
type definition plus a default since before the git era, but has never
offered the equivalent for the other three types. Conor Dooley ran into
this gap[1] when fixing a symbol that had been given the wrong type:
Unfortunately, there is no such thing as "def_string", but in this
case we can use "default" to propagate the value of ...
Nothing in the grammar requires the restriction. The rule that consumes
a default is already type agnostic. Add the three missing types. No
changes are needed to existing diagnostics. E.g. declaring a symbol
"bool" and then assigning it with "def_string" still reports
warning: ignoring type redefinition of 'CONFLICT' from 'bool' to 'string'
Added tests for the types.
Build tested ARCH=x86_64 with GCC 16.2.0. Tests pass with "make testconfig".
Link: https://lore.kernel.org/all/20230111104848.2088516-1-conor.dooley@microchip.com/ [1]
Assisted-by: LLM
Signed-off-by: Kees Cook <kees@kernel.org>
Tested-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Julian Braha <julianbraha@gmail.com>
Link: https://patch.msgid.link/20260919005929.4077729-1-kees@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
randconfig checks the numeric range of each probability but does not
validate where strtol() stops. For example, KCONFIG_PROBABILITY=50% is
accepted as 50:0:0: the '%' is parsed repeatedly as zero. For the
documented value 50, tristate y/m/n probabilities are 25%/25%/50%.
With 50%, both y/m probabilities silently become zero, reducing the
coverage of random configuration builds. Empty fields and extra fields
are also accepted.
Warn when the value does not follow the documented decimal format. For
malformed inputs whose parsed probabilities are in range, preserve the
existing interpretation unless KCONFIG_WERROR is set. In that case, exit
with an error before writing the configuration. Leading whitespace and
signs are accepted by strtol(), but also trigger the warning because they
are outside the documented format.
Keep the strtol() result as long until the range check. This rejects
out-of-range values that narrowing to int previously made valid, such as
4294967296 becoming zero on a 64-bit host, regardless of KCONFIG_WERROR.
Add regression tests for one warning per malformed input, preserved
configurations, KCONFIG_WERROR, out-of-range values, the supported
probability formats, and the documented empty-value default.
Fixes: e43956e607 ("kconfig: implement KCONFIG_PROBABILITY for randconfig")
Assisted-by: LLM
Signed-off-by: Dmitrii Tulnov <tulnov.dl@gmail.com>
Tested-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Julian Braha <julianbraha@gmail.com>
Link: https://patch.msgid.link/20260918213430.3-1-tulnov.dl@gmail.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Commit d50f210913 ("kbuild: align modinfo section for Secureboot
Authenticode EDK2 compat") aligned .modinfo because it appeared in the
x86_64 compressed kernel image after commit 3e86e4d74c ("kbuild: keep
.modinfo section in vmlinux.unstripped"), breaking boot.
Commit 8678591b47 ("kbuild: Split .modinfo out from ELF_DETAILS")
properly addresses .modinfo appearing in unexpected contexts like
compressed images by moving it out of ELF_DETAILS and explicitly
specifying its location in every architecture's vmlinux linker script or
discarding it where it may appear elsewhere.
Effectively revert commit d50f210913 ("kbuild: align modinfo section
for Secureboot Authenticode EDK2 compat") and its follow up fix,
commit a26a6c93ed ("kbuild: Strip trailing padding bytes from
modules.builtin.modinfo"), as they are no longer necessary in the
current tree. This simplifies future cleanups.
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Link: https://patch.msgid.link/20260918005142.GA1585590@ax162/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
- kbuild: don't delete in-flight filechk temporaries in asm-headers
A rule for generating header files was changed from using make
$(wildcard) fnglob to 'find' instead; as 'find' finds "hidden" files
by default, temporary files from Kbuild's 'filechk', used for
generating asm header files, may get deleted and break header file
generating.
- scripts/sorttable: Mark long_size as __maybe_unused
Fix builds with clang-23 or newer on trees w/o commit b055f4c431
("sorttable: Move ELF parsing into scripts/elf-parse.[ch]");
targetting for backport to stable kernels < 6.19.
- scripts/mksysmap: drop the MODULE_INFO() symbols from kallsyms
Update regexp to remove kallsyms entries from kernel binary, saves
about 32 KiB of bzImage.
- scripts/mksysmap: fix escape of '$' in the __pi_ pattern
Prevent arm64 PIE namespace local symbols from appearing System.map
and /proc/kallsyms.
Cc: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nicolas Schier <n.schier@fritz.com>
Cc: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Cc: Vlad Poenaru <vlad.wing@gmail.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEh0E3p4c3JKeBvsLGB1IKcBYmEmkFAmqlk5UACgkQB1IKcBYm
Eml4QxAAx44wbbabtE6Ebwrm2fa8Np2NoJNfDtUb9KiTuMhybdswlpomcbXSGnri
GZjeQOs+PPZMwsCVTffB+2ACevvGW+v/Ve68Aotc+iEQsMQnxnGlOTG1utmcgHEN
NKpg3ESHh2QbQ6QP684h1HnOETVQelaFWezZZq6gtXYsBEaJnLdyskeNyFMiN2Jk
t+h07mHTf9qgWzCb6WoWgokJj1uZgQwfgUfHM0hGxnrDXYh93mIWDy8FzuCY8LCl
V+4jEUT5JQltP4ts8Q0gVgxGx83l0WxxswR00afuWL9nLyJ5jhH+TCA+Q6/D7OtM
CHnZG+qi8K2qdT/nSMyaPzPrPhGIYFMBcXCT512jQGw7QeEME5xC9ebTSONxlV0G
sMblzynFj+Hi7rAl8rNEbpj4madgpQdfXoYhLbZiP5XniWhQeYEIovw7pQa7AiQ1
BftAaHPghBDKLOEBizLw4CDOdApRS8nAhjXJeRffaADUpuwhVpxX++7UpBYgICne
/mfUv2D+qO08ASJy8RN06iCl2pzwVYPD+IjDk0ssDVYD92RKvVaT7H1fsOaxAObN
pa4KUSCShWNLkNn8pnybRpFngyI5jq0p/A/h+V7iH45y5IdF2NWkPag2gG3nJhpc
OF8v7V394NPqrZiFER087/jUes7hCmMotdIyAsztKh4GnB2h23s=
=FqqV
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQR74yXHMTGczQHYypIdayaRccAalgUCaq2rtgAKCRAdayaRccAa
lisJAP9N2NeP1ejkLsxbJ3eJT6+jt3xek55yc1CoI1L9xH87QQD/YzMr+nXopBJw
uXBX7wB16Ucf6R1pA6C1RmqTZwMfMQA=
=N3xO
-----END PGP SIGNATURE-----
Merge tag 'kbuild-fixes-7.3-1' into kbuild-next
Future changes in kbuild-next depend on
281b61d408 ("scripts/mksysmap: drop the MODULE_INFO() symbols from kallsyms")
59351365ac ("scripts/mksysmap: fix escape of '$' in the __pi_ pattern")
from kbuild-fixes.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Update the internal kconfig check to print a warning on 'select' and
'imply' statements that target on choice values.
Julian Braha reported that kconfig's 'select' and 'imply' do not work
for choice values but have no effect all. Show a warning instead of
error-out to allow kconfig to check the whole kconfig rule set.
Reported-by: Julian Braha <julianbraha@gmail.com>
Closes: https://lore.kernel.org/linux-kbuild/20260715220149.48700-1-julianbraha@gmail.com/ # [1]
Suggested-by: Kees Cook <kees@kernel.org>
Suggested-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Nicolas Schier <nsc@kernel.org>
Reviewed-by: Julian Braha <julianbraha@gmail.com>
Tested-by: Julian Braha <julianbraha@gmail.com>
Link: https://patch.msgid.link/20260804-kconfig-warn-on-dead-select-for-choice-value-v1-1-e5c9a274d291@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
While 'hex' values should use the bounds of 64-bit unsigned integers, the
range values are treated as signed (checks use strtoll).
For example:
config HEX_RANGE
hex
range 0 0xfffffffffffffffe
default 0xffffffffffffffff
the default value should adjust down to the upper bound of
0xfffffffffffffffe, but since the check incorrectly parses both as
LLONG_MAX, the value stays at the out-of-range default of
0xffffffffffffffff.
To fix this, let's use a union of signed and unsigned integers to
represent both 'int' and 'hex' range values, then use both strtoll and
strtoull where appropriate.
Assisted-by: LLM
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Link: https://patch.msgid.link/20260915211508.291790-6-julianbraha@gmail.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Currently, user input of out-of-bounds values for 'int' and 'hex' options
is possible, leading to later silent failures in Kconfig if that value is
used in a comparison, or a warning by GCC or error by Clang if used in the
C code.
Let's factor out the out-of-bounds check on constants, so that it can be
reused for checking user input.
The frontend will now reject an attempted user input of an out-of-bounds
numeric value, similarly to how a value outside the active 'range' already
does.
For migration of existing configurations, a .config file with an
out-of-bounds numeric value will be allowed for now, but will warn the
user when read in by confdata.c
Assisted-by: LLM
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Link: https://patch.msgid.link/20260915211508.291790-5-julianbraha@gmail.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Using a numeric option of one type (e.g. 'int') to determine the value of
a different numeric type (e.g. 'hex') currently fails silently in various
ways if attempted, because the underlying string representation is naively
reused.
Example 1:
config I
int
default -1
config HEX_DEFAULT_INT
hex
default I
Here, HEX_DEFAULT_INT actually gets set to '0x-1', which is of course not
a valid hex value.
Example 2:
config H
hex
default A
config INT_DEFAULT_HEX
int
default H
Here, INT_DEFAULT_HEX actually gets set to 'A', without even converting
into the base-10 equivalent of 10. This value, 'A', is otherwise a
rejected int value if entered in the frontend, or read in from an existing
.config file.
These int-hex mismatches currently do not appear anywhere in the tree, so
it is already safe to make these error out.
Assisted-by: LLM
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Link: https://patch.msgid.link/20260915211508.291790-4-julianbraha@gmail.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
The Kconfig interpreter internally represents constants as strings, then
attempts to parse them as 64-bit signed integers for 'int' options, and
64-bit unsigned integers for 'hex' options.
However, there is currently no check that the conversion succeeds, leading
to failures when the values are actually used. For example:
config LARGE_INT
int
default 10000000000000000000
config BUGGED_INT_COMPARISON
bool
default y if LARGE_INT < 2
Obviously 10000000000000000000 is larger than 2, but the Kconfig
interpreter will fallback to comparing the two values with strcmp() after
the numeric conversion fails, causing the first character, '1', to be
compared with '2', and giving the wrong result.
Since none of these out-of-bounds values are used as constants anywhere in
the tree, we can already make these error out.
Assisted-by: LLM
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Link: https://patch.msgid.link/20260915211508.291790-3-julianbraha@gmail.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
The Kconfig interpreter already warns if a numeric option attempts to use
a non-numeric option (bool, tristate, or string) to set its value (for
example, with a 'default' or 'range').
Since there is nowhere in the tree that attempts this, we can safely
promote this check from warning to error.
Assisted-by: LLM
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Link: https://patch.msgid.link/20260915211508.291790-2-julianbraha@gmail.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
The Kconfig interpreter currently allows defaults that are outside of the
range bounds.
In these cases, the 'sym_validate_range' function will adjust the default
value to the nearest range bound. For example, see this example:
config A
int
range 1 2
default 16
Here, since the default value of 16 is greater than the bounds, the
effective default value gets adjusted down to the upper bound, 2.
However, 'savedefconfig' writes non-default values, and without being
aware of the automatic adjustment to the range bound, it would write: A=2
This limitation is also documented in a comment: "The following fails to
handle the situation where a default value is further limited by the valid
range."
To resolve this, let's factor out the default-range adjustment logic from
the existing 'sym_validate_range' function into its own
'sym_get_near_range_bound' function for 'savedefconfig' to use too, so
that it compares against the effective value.
Adds tests, accordingly.
Fixes: 7cf3d73b43 ("kconfig: add savedefconfig")
Assisted-by: Codex:gpt-5.6-sol
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Closes: https://lore.kernel.org/lkml/CAMuHMdVyUAA3L4mUkSjmnuE3cvj-+N8z-Bhxsh1wa-FQWc=fjw@mail.gmail.com/
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://patch.msgid.link/20260830221129.2668354-1-julianbraha@gmail.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Commit b18b047002 ("kbuild: change scripts/mksysmap into sed script")
converted scripts/mksysmap from a shell script to a sed script.
However an error was made - escaping of '$' required \\ escaping in shell
but only \ in a sed script.
This was mostly corrected in commit 7a6c355b55 ("scripts/mksysmap: Fix
escape chars '$'"), but this fix missed arm64 PIE namespace local symbols
like __pi_$x and __pi_$d which appear in System.map and /proc/kallsyms:
$ grep __pi_\\$ /proc/kallsyms | sort -u
0000000000000000 d __pi_$d
0000000000000000 t __pi_$x
Fix the escaping properly.
Fixes: b18b047002 ("kbuild: change scripts/mksysmap into sed script")
Assisted-by: LLM
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Link: https://patch.msgid.link/20260908-build-speedup-v1-2-5dc1ac01672d@kernel.org
Signed-off-by: Nicolas Schier <nsc@kernel.org>
Commit 3e86e4d74c ("kbuild: keep .modinfo section in vmlinux.unstripped")
keeps .modinfo symbols out of System.map and kallsyms, which assumes unique
IDs have a format like '__UNIQUE_ID_modinfo123'.
However, commit afb026b6d3 ("compiler: Tweak __UNIQUE_ID() naming"), sent
in the same cycle, changes this to '__UNIQUE_ID_modinfo_123'.
As a result this regexp has never matched and every kernel since v6.18 has
carried one kallsyms entries for every MODULE_INFO() declaration in the
kernel whether the modules are compiled or not.
That's 5,810 entries for an x86 defconfig build and 15,200 for arm64.
On x86 defconfig that is 113 KiB of kallsyms tables and 32 KiB of bzImage,
and every lookup walks past them.
Fix the pattern.
Fixes: 3e86e4d74c ("kbuild: keep .modinfo section in vmlinux.unstripped")
Assisted-by: LLM
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://patch.msgid.link/20260908-build-speedup-v1-1-5dc1ac01672d@kernel.org
Signed-off-by: Nicolas Schier <nsc@kernel.org>
When building in a kernel tree prior to commit b055f4c431 ("sorttable:
Move ELF parsing into scripts/elf-parse.[ch]") with clang-23 or newer,
which implements a new warning under -Wunused-but-set-variable for
static global variable, there is a warning from sorttable because
long_size is unused when MCOUNT_SORT_ENABLED is not set:
scripts/sorttable.c:452:12: error: variable 'long_size' set but not used [-Werror,-Wunused-but-set-global]
452 | static int long_size;
| ^
Mark long_size as __maybe_unused to avoid inserting more ugly #ifdef
directives while insuring the warning does not reappear, as the
aforementioned change does not alter the uses of long_size, so it
appears to be coincidence that the warning disappears after this
refactoring.
Cc: stable@vger.kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nicolas Schier <n.schier@fritz.com>
Link: https://patch.msgid.link/20260831-sorttable-long_size-unused-but-set-global-v1-1-8a96b88697e5@kernel.org
Signed-off-by: Nicolas Schier <nsc@kernel.org>
Commit 2d69b891e6 ("kbuild: Support generated asm-headers in
subdirectories") switched the stale-wrapper sweep in
scripts/Makefile.asm-headers from $(wildcard $(obj)/*.h) to a find(1)
invocation, so that generated headers in subdirectories are considered.
The two do not match the same set of files. Make's $(wildcard) uses glob
semantics, where a leading '.' has to be matched explicitly, whereas
find's -name uses fnmatch() without FNM_PERIOD, so '*.h' matches
dotfiles as well. filechk writes its output to $(dir $@).tmp_$(notdir $@)
before renaming it into place, so such a scratch file, if it happens to
exist in $(obj) when the sub-make is parsed, is now picked up in
old-headers. It appears in neither generic-y, generated-y nor syscall-y,
is therefore classified as unwanted, and cmd_remove deletes it.
On x86 this races with archprepare, which lists both asm-generic and
arch/x86/include/generated/asm/cpufeaturemasks.h as prerequisites. Under
-j they run concurrently against the same directory, and the build fails
intermittently:
mv: cannot stat 'arch/x86/include/generated/asm/.tmp_cpufeaturemasks.h': No such file or directory
make[1]: *** [arch/x86/Makefile:269: arch/x86/include/generated/asm/cpufeaturemasks.h] Error 1
The same commit also converted the generic wrapper rule to filechk, so
those wrappers now create .tmp_*.h in $(obj) too and can race among
themselves.
Restore the previous behaviour by excluding dotfiles from the sweep.
Subdirectories, which is what the find(1) conversion was for, keep being
descended into. While at it, quote the -name argument: it is currently
expanded by the shell against the build directory before find sees it.
Fixes: 2d69b891e6 ("kbuild: Support generated asm-headers in subdirectories")
Signed-off-by: Vlad Poenaru <vlad.wing@gmail.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Link: https://patch.msgid.link/20260902161347.4163577-1-vlad.wing@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
With GCC plugins enabled, external module builds can record
-fplugin=... paths in DWARF producer metadata via
-grecord-gcc-switches, leaking host/build specific paths and
triggering QA checks.
Handle this in scripts/Makefile.gcc-plugins for KBUILD_EXTMOD
builds by adding -gno-record-gcc-switches to plugin cflags.
This keeps plugin behavior unchanged while avoiding absolute
plugin path leakage in external module debug metadata.
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/all/20260817185146.GC1249844@ax162/
Signed-off-by: Jaihind Yadav <jaihindy@qti.qualcomm.com>
Link: https://patch.msgid.link/20260820060116.786173-1-jaihindy@qti.qualcomm.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
The tag variable is only used by try_tag(), but is currently declared
local to scm_version() and modified by try_tag().
Make tag local to try_tag() instead and remove the unused declaration
from scm_version().
No functional changes.
Signed-off-by: Yuntao Wang <yuntao.wang@linux.dev>
Link: https://patch.msgid.link/20260823094913.421144-1-yuntao.wang@linux.dev
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
The assignment of LINUX_COMPILE_HOST uses the classic backtick style
for its command substitution but the rest of the script uses the more
common '$()'. Update LINUX_COMPILE_HOST to match for consistency.
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
Link: https://patch.msgid.link/20260818204804.2985008-1-unixbhaskar@gmail.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Currently, it is possible to create recursive ranges with Kconfig, such as:
config C
int "Enable C"
default 1
range A B
config A
int "Enable A"
default 2
range B C
config B
int "Enable B"
default 3
range A C
The current outcome of this example above, is that all 3 options are set to 2.
There is currently no warning or error if a user attempts this.
Several attributes are already checked for recursion, including 'depends on',
'select', and 'imply', and we can extend this to 'range' for numeric options
(int and hex types).
Recursive ranges are currently not used anywhere in the tree, so it is already
safe to make this a hard error.
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Link: https://patch.msgid.link/20260816215354.1499059-1-julianbraha@gmail.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Sang-Heon Jeon <ekffu200098@gmail.com> has cleaned up a number
of the semantic patches in the scripts/coccinelle directory,
particularly with respect to functions that no longer exist in
the kernel. He and I have also done some reorganizations that
improve performance.
I eliminatd some false positives.
相浦彰 / AIURA，AKIRA <akira.aiura.bj@hitachi.com> fixed an
out of date URL.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEnGZC8gbRfLXdcpA0F+92B3f5RZ0FAmqUJzoACgkQF+92B3f5
RZ1ZKA//XmJPmm4VapiaWb3Kd9R11JXEqUrkDMkexkwpa+844xC6XfUKsAJTsxff
18UksaPH+GQyLInWtu271uPDL+3X/yXbSU0iQA675XVQsG9Bz9MJ3R7tDcmFiJR9
Oflm7VwlG0QFVk1HVJRtY5+kfZ5ob54CZ82QltHCRIrPKQJ9JWqS8ffnNggLQu91
D079YK9gL/SqTXsWSUg+oU/TN5zILAZ0XDAdqN5THuMtq3ADurlKoPFeGHTiXdDs
rFlmbu3XX40aL06qun6B4WLD/86fpvaVQ9NwqJnTEoTA4GNwENY/wYY9GJdsWa7h
N7bTB7R8g441orRx0CeGyFBJkNocg4V5ImT42aGtsxfgIxDvFPxcfVg3TnCSbO8/
SYvvnzaIzdYkx41IIIHPLZHNbW96kbT8rI5s3DrkUoKvMePnCtrV/6bR1QFBHdiw
I5/q4yhFjwvRh5ffiU5McqlYcM4NK1s3lHD+fk6oKf8XOgPzo6b1nBFky+P4Whw+
Sy/uBM2TrafRlvRrctz0EdhKSQede/Q7OVFcJKOvUUwnYKRqmrM5qPIQvDg6s4zZ
7NQWK7SsfWFKFUd1mljqN9Pe//fLIxfHKqyQwWtoPJwPmVaKSUTF/UDHu5HR4VVn
wd4MxZj1ck3Dv/mtvAcJNxKw3+imD+284wPkpsrityMDpdYRHoc=
=AgiL
-----END PGP SIGNATURE-----
Merge tag 'cocci-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux
Pull Coccinelle updates from Julia Lawall:
- Clean up a number of the semantic patches in the scripts/coccinelle
directory, particularly with respect to functions that no longer
exist in the kernel (Sang-Heon Jeon)
He and I have also done some reorganizations that improve
performance.
- Eliminate some false positives (me)
- Fix an out of date URL (相浦彰)
* tag 'cocci-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux:
coccinelle: ifnulldev_put: update error message
coccinelle: ifnulldev_put: update outdated helper names
coccinelle: atomic_as_refcounter: drop atomic_long_dec_and_lock
coccinelle: kfree_mismatch: drop vmalloc_exec
coccinelle: pool_zalloc-simple: drop the pci_pool_alloc rules
coccinelle: zalloc-simple: drop the kmem_alloc rules
coccinelle: alloc_cast: drop removed allocators
coccinelle: remove obsolete pci_free_consistent.cocci
scripts: coccinelle: devm_free: reduce false positives
coccinelle: misc: struct_size: drop unneeded parentheses
coccinelle: mini_lock: improve performance when searching loops
coccinelle: api: check for macro context
coccinelle: update Coccinelle website URL
coccinelle: misc: minmax: avoid unhelpful isomorphisms
coccinelle: misc: minmax: check for the presence of if cases
coccinelle: misc: minmax: drop unneeded parentheses
coccinelle: misc: minmax: improve performance when no candidate exists
coccinelle: double_lock: improve performance when no double lock exists
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.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEPjU5OPd5QIZ9jqqOGXyLc2htIW0FAmqT+BIACgkQGXyLc2ht
IW0vRRAAmR1E04gT5HFDH+iNJgLlyticVsHs0rH46ICYgQWs+gpGGiJsPpnNBJxM
M5+VGauMPch5kIBKYwD/XrUe6cDDNqIfY8Eq+BnJiTxDe6U68K4cSnmPe478wZIn
15AIteCHN2x9vf49KpfI3fH/xoriS5XVEC915bQ9APXOYJv7iXZCFDzxw9dXnYu/
TE3YleA32oJ9COBT3s8ovtzNpEOtZPKhWFd2lOCaGbxBLWygu5X/PSEZs6ikmqgR
BqHrbhzSco8aYKCrbFbQrdgtwFPr3PQ8pRn44TPU6/siZNVBk83IpcxdtXrQ2gRi
wOwZfMsH2K/cEZWMXPz16hp+4onWUr1bgkfLUAzPtyqUX6rOEaBrliSXGs+yCl40
KNx5BefrhzH6UL+/pbLGVXzC5q1VLTsgS6u66piUyvhf52Wmvzc7AExGml/BWA/q
jomwnxpgLiBjO61cH4dnfrm3AtXHAWGzG/dd0BnVcpT+8HEr2W4WWRSydmPtkB+f
hXXmwAOF3sgVueJ2nxlPVcqt3LdsinCwBrQQmO8J+TtPyNW9sh72OfFSOkF/wybw
o5tcqFG7ZSNGR7pli5pYsnG4Gfv3vIraLwhiVciGXZ+es+FkKtOpaOMunUcQwKP6
+uFpdMqXVQmH4l3Adc0rG1lq6zRHnGvZ96R5PlmPhl6RVDZuv0E=
=EBLX
-----END PGP SIGNATURE-----
Merge tag 'rust-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
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
dev_put_track() and dev_hold_track() were renamed to netdev_put() and
netdev_hold() by commit d62607c3fe ("net: rename reference+tracking
helpers").
So update the names.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
atomic_long_dec_and_lock() has never existed. So drop it from the rules.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
vmalloc_exec() was removed by commit 7a0e27b2a0 ("mm: remove
vmalloc_exec").
So drop it from the rules.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
pci_pool_alloc() and pci_pool_zalloc() were removed by commit
88dee3b0ef ("PCI: Remove unused pci_pool wrappers").
So drop the pci_pool_alloc rules.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Here is the big set of char, misc, iio, counter, fpga, and other small
driver subsystems for 7.3-rc1.
Overall, due to some driver removals we only added a bit more code than
removed, which was a nice change. Highlights in this merge request are:
- Loads of IIO driver updates and additions
- binder driver updates (more on that below...)
- Removal of the SGI XP and GRU drivers as they are not used anymore
and turn out to be pretty insecure overall
- Removal of the obsolete ibmasm driver as it's not being used anymore
- Coresight driver updates and additions
- Mei driver udpates
- Counter driver updates
- FPGA driver updates
- ICC driver updates
- lots and lots of other tiny driver updates to resolve reported
issues
All of these have been in linux-next for a while, with the only reported
issues being some major merge conflicts. Miguel pointed out some of
these with the Rust tree merge, which is the majority of them. I'll
follow up with a diffstat of the merge resolution I made against your
most recent tree, which works for me.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCao143A8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymtUgCeKB62gT1JfA86cg3NDB1opp+10N0An3oBBegQ
IJLqJgK45dTNtMGBwGFV
=68af
-----END PGP SIGNATURE-----
Merge tag 'char-misc-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc/IIO/etc driver updates from Greg KH:
"Here is the big set of char, misc, iio, counter, fpga, and other small
driver subsystems for 7.3-rc1.
Overall, due to some driver removals we only added a bit more code
than removed, which was a nice change. Highlights in this merge
request are:
- Loads of IIO driver updates and additions
- binder driver updates (more on that below...)
- Removal of the SGI XP and GRU drivers as they are not used anymore
and turn out to be pretty insecure overall
- Removal of the obsolete ibmasm driver as it's not being used
anymore
- Coresight driver updates and additions
- Mei driver udpates
- Counter driver updates
- FPGA driver updates
- ICC driver updates
- lots and lots of other tiny driver updates to resolve reported
issues
All of these have been in linux-next for a while"
* tag 'char-misc-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (513 commits)
iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF
iio: adc: pac1921: fix wrong channel used in trigger handler read
iio: light: gp2ap002: re-enable irq if runtime suspend fails
iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes
iio: light: apds9306: fix PM reference leak in apds9306_read_data()
iio: gyro: mpu3050: fix sign of raw angular velocity readings
iio: srf04: fix pm_runtime handling on probe error path
iio: adc: ad4080: configure backend data size
iio: adc: adi-axi-adc: add data size support for AD408X backend
iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable
iio: dac: ad5446: fix OF module device table
iio: light: opt4001: Fix reversed GENMASK() arguments in fault count mask
iio: light: opt4001: Reject integration times with a non-zero seconds part
iio: light: opt4001: Fix incompatible pointer type passed to div_u64_rem()
iio: light: opt4001: Fix power down clearing bits of the wrong register
iio: light: opt4060: Fix incorrect register name in threshold read error message
iio: light: opt4060: Fix pointer type passed to div_u64_rem()
iio: light: opt4060: Reject integration times with a non-zero seconds part
iio: light: ltrf216a: fix runtime PM reference leak in error path
iio: pressure: dps310: fix NULL pointer dereference on ACPI probe
...
- kmem_alloc() was removed by commit f078d4ea82
("xfs: convert kmem_alloc() to kmalloc()")
- kmem_zalloc() was removed by commit 10634530f7
("xfs: convert kmem_zalloc() to kzalloc()")
So drop the kmem_alloc rules.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
- pci_alloc_consistent() and pci_zalloc_consistent() were removed by
commit 7968778914
("PCI: Remove the deprecated "pci-dma-compat.h" API")
- kmem_alloc() was removed by commit f078d4ea82
("xfs: convert kmem_alloc() to kmalloc()")
- kmem_zalloc() was removed by commit 10634530f7
("xfs: convert kmem_zalloc() to kzalloc()")
- kmem_zone_alloc() and kmem_zone_zalloc() were removed by commit
bae633a4a2 ("xfs: remove xfs_zone_{alloc,zalloc} helpers")
So drop them from the rules.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
pci_alloc_consistent() and pci_free_consistent() were removed by commit
7968778914 ("PCI: Remove the deprecated "pci-dma-compat.h" API").
So remove the obsolete script.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
False positives could be introduced due to allocations using the new
_obj functions. Add these to the "safe" rule accordingly.
False positives could also be introduced when the same variable
name has two possible types. Incorporate type information to avoid
reporting this case This does lead to false negatives when no type
information is available.
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Reported-by: Ricardo Ribalda <ribalda@chromium.org>
The outer parentheses and the single-branch disjunction don't matter when
just matching and reporting a line. Eliminating them reduces the
complexity of the pattern to match and gives a performance improvement in
the non-patch cases, like the previous minmax change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
The 'looped' rule collects the returns inside a for loop to
prevent 'err' from reporting them. It searches every for loop in
the file, and on files with large loop bodies the search explodes.
For example, kernel/bpf/verifier.c runs for over 200 seconds,
almost entirely in 'looped' according to --profile. Since the
kernel .cocciconfig sets a 200 second timeout, coccicheck silently
skips the file.
To avoid this, collect the candidate returns first, so that
'looped' checks only those positions. 'err' then excludes what
'looped' found.
Every return that 'err' can report is also a candidate, so the
same returns are excluded as before and the output does not change.
A report-mode run over every .c file in the tree produces identical
output.
So verifier.c now finishes well within the timeout, in a few
seconds.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
A cast on a call to an allocation function that is the body of a macro can
be useful, as it ensures tha the macro is used for allocating objects of
the right type. Add two new rules to ignore the macro case.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
The old Coccinelle project URL is no longer available. Replace it with
the current Coccinelle homepage already referenced by
Documentation/dev-tools/coccinelle.rst.
Signed-off-by: Akira Aiura <akira.aiura.bj@hitachi.com>
Signed-off-by: Julia Lawall <julia.lawall@inria.fr>
