Add support for the %{?dist} macro in the kernel.spec file. This enables
building and releasing kernel RPMs with a custom distribution suffix
(e.g., via rpmbuild's --define option) to better match production
environment tracking.
Signed-off-by: Yafang Shao <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Nathan Chancellor <[email protected]>
The current minimum version of LLVM for building the kernel is 15.0.0.
However, there are two deficiencies compared to GCC that were fixed in
LLVM 17 that are starting to become more noticeable.
The first was a bug in LLVM's scope checker [1], where all labels in a
function were validated as potential targets of an asm goto statement,
even if they were not listed in the asm goto statement as targets. This
becomes particularly problematic when the cleanup attribute is used, as
asm goto(... : label_a);
...
label_a:
...
int var __free(foo);
asm goto(... : label_b);
...
label_b:
...
will trigger an error since the scope checker will complain that the
cleanup variable would be skipped when jumping from the first asm goto
to label_b (which obviously cannot happen). This issue was the catalyst
for commit e2ffa15b9b ("kbuild: Disable CC_HAS_ASM_GOTO_OUTPUT on
clang < 17"). Unfortunately, this issue is reproducible with regular asm
goto in addition to asm goto with outputs, so that change was not
entirely sufficient to avoid the issue altogether. As asm goto has
effectively been required since commit a0a12c3ed0 ("asm goto:
eradicate CC_HAS_ASM_GOTO") and the usage of the cleanup attribute
continues to grow across the tree, raising the minimum to a version that
avoids this issue altogether is a better long term solution than
attempting to workaround it at every spot where it happens.
The second issue is an incompatibility with GCC 8.1+ around variables
marked with const being valid constant expressions for _Static_assert
and other macros [2]. With GCC 8.1 being the minimum supported version
since commit 118c40b7b5 ("kbuild: require gcc-8 and binutils-2.30"),
this incompatibility becomes more of a maintenance burden since only
clang-15 and clang-16 are affected by it.
Looking at the clang version of various major distributions through
Docker images, no one should be left behind as a result of this bump, as
the old ones cannot clear the current minimum of 15.0.0.
archlinux:latest clang version 22.1.3
debian:oldoldstable-slim Debian clang version 11.0.1-2
debian:oldstable-slim Debian clang version 14.0.6
debian:stable-slim Debian clang version 19.1.7 (3+b1)
debian:testing-slim Debian clang version 21.1.8 (3+b1)
debian:unstable-slim Debian clang version 21.1.8 (7+b1)
fedora:42 clang version 20.1.8 (Fedora 20.1.8-4.fc42)
fedora:latest clang version 21.1.8 (Fedora 21.1.8-4.fc43)
fedora:44 clang version 22.1.1 (Fedora 22.1.1-2.fc44)
fedora:rawhide clang version 22.1.3 (Fedora 22.1.3-1.fc45)
opensuse/leap:latest clang version 17.0.6
opensuse/tumbleweed:latest clang version 21.1.8
ubuntu:jammy Ubuntu clang version 14.0.0-1ubuntu1.1
ubuntu:noble Ubuntu clang version 18.1.3 (1ubuntu1)
ubuntu:questing Ubuntu clang version 20.1.8 (0ubuntu4)
ubuntu:resolute Ubuntu clang version 21.1.8 (6ubuntu1)
17.0.1 is chosen as the minimum instead of 17.0.0 to ensure that the
particular version of LLVM 17 has the two aforementioned bugs fixed, as
the second was fixed during the 17.0.0 release candidate phase and it
was not until LLVM 18 that LLVM adopted the scheme of x.0.0 being a
prerelease version and x.1.0 is a release version [3] to help with
scenarios such as this.
Link: https://github.com/llvm/llvm-project/commit/f023f5cdb2e6c19026f04a15b5a935c041835d14 [1]
Link: https://github.com/llvm/llvm-project/commit/0b2d5b967d98375793897295d651f58f6fbd3034 [2]
Link: https://github.com/llvm/llvm-project/commit/4532617ae420056bf32f6403dde07fb99d276a49 [3]
Acked-by: Nicolas Schier <[email protected]>
Link: https://patch.msgid.link/20260517-bump-minimum-supported-llvm-version-to-17-v2-1-b3b8cda46bdd@kernel.org
Signed-off-by: Nathan Chancellor <[email protected]>
This adds support for Software Tag-Based KASAN (KASAN_SW_TAGS) when
CONFIG_RUST is enabled. This requires that rustc includes support for
the kernel-hwaddress sanitizer, which is available since 1.96.0 [1].
Unlike with clang, we need to pass -Zsanitizer-recover in addition to
-Zsanitizer because the option is not implied automatically.
The kasan makefile uses different names for the flags depending on
whether CC is clang or gcc, but as we require that CC is clang when
using KASAN, we do not need to try to handle mixed gcc/llvm builds when
Rust is enabled.
Link: https://github.com/rust-lang/rust/pull/153049 [1]
Reviewed-by: Danilo Krummrich <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
This patch enables AutoFDO build support for Rust code within the Linux
kernel. This allows Rust code to be profiled and optimized based on the
profile.
The RUSTFLAGS variable was suffixed with *_AUTOFDO_CLANG to match the
naming of the config option, which is called CONFIG_AUTOFDO_CLANG.
This implementation has been verified in Android, first by inspecting
the object files and confirming that they look correct. After that,
it was verified as below:
1. Running the binderAddInts benchmark [1] with Rust Binder built as
rust_binder.ko module, using a Pixel 9 Pro.
2. Collecting a profile on a Pixel 10 Pro XL using the app-launch
benchmark, which starts different apps many times, on a device with
Rust Binder as a built-in kernel module. (C Binder was not present on
the device.)
3. Using the collected profile, run the binderAddInts benchmark again
with Rust Binder built both as a rust_binder.ko module, and as a
built-in kernel module.
4. In both cases, Rust Binder without AutoFDO was approximately 13%
slower than the AutoFDO optimized version. Built-in vs .ko did not
make a measurable performance difference.
All of the above was verified in conjunction with my helpers inlining
series [2], which confirmed that this worked correctly for helpers too
once [3] was fixed in the helpers inlining series.
Link: https://android.googlesource.com/platform/system/extras/+/920f089/tests/binder/benchmarks/binderAddInts.cpp [1]
Link: https://lore.kernel.org/r/[email protected] [2]
Link: https://lore.kernel.org/r/[email protected] [3]
Reviewed-by: Rong Xu <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Acked-by: Nicolas Schier <[email protected]>
Acked-by: Nathan Chancellor <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ Reworded for typos. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
The chip name column in the /proc/interrupt output is 8 characters and
right aligned, which causes visual clutter due to the fixed length and the
alignment. Many interrupt chips, e.g. PCI/MSI[X] have way longer names.
Update the length when a chip is assigned to an interrupt and utilize this
information for the output. Align it left so all chip names start at the
begin of the column.
Update the GDB script as well and disentangle the header maze so it
actually works with all .config combinations.
Signed-off-by: Thomas Gleixner <[email protected]>
Tested-by: Michael Kelley <[email protected]>
Reviewed-by: Dmitry Ilvokhin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Quite some architectures have four character wide acronyms for architecture
specific interrupts like IPI, NMI, etc.
The default precision of printing the Linux device interrupt numbers is
three, which causes quite some code to play games with adding or omitting
space after the acronym and the colon in order to keep the per CPU numbers
properly aligned.
Increase the default number precision to four in the core code and get rid
of the space games all over the place. At the same time align all
architecture specific descriptor texts left so that they show up in the
same column as the interrupt chip names, which makes the output more
uniform accross architectures. Fix up the GDB script to this new scheme as
well.
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://patch.msgid.link/[email protected]
x86 changed the interrupt statistics from a struct with individual members
to an counter array. It also provides a corresponding info array with the
strings for prefix and description and an indicator to skip the entry.
Update the already out of sync GDB script to use the counter and the info
array, which keeps the GDB script in sync automatically.
Signed-off-by: Thomas Gleixner <[email protected]>
Tested-by: Florian Fainelli <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Link: https://patch.msgid.link/[email protected]
The Makefile version of rustc-option currently checks whether the option
exists for the host target instead of the target actually being compiled
for. It was done this way in commit 46e24a545c ("rust: kasan/kbuild:
fix missing flags on first build") to avoid a circular dependency on
target.json. However, because of this, rustc-option currently does not
function when cross-compiling from x86_64 to aarch64 if
CONFIG_SHADOW_CALL_STACK is enabled. This is because KBUILD_RUSTFLAGS
contains -Zfixed-x18 under this configuration. Since that flag does not
exist on the host target, rustc-option runs into a compilation failure
every time, leading to all flags being rejected as unsupported.
To fix this, update rustc-option to pass a --target parameter so that
the host target is not used. For targets using target.json, use a
built-in target that is as close as possible to the target created with
target.json to avoid the circular dependency on target.json.
One scenario where this causes a boot failure:
* Cross-compiled from x86_64 to aarch64.
* With CONFIG_SHADOW_CALL_STACK=y
* With CONFIG_KASAN_SW_TAGS=y
* With CONFIG_KASAN_INLINE=n
Then the resulting kernel image will fail to boot when it first calls
into Rust code with a crash along the lines of "Unable to handle kernel
paging request at virtual address 0ffffffc08541796". This is because the
call threshold is not specified, so rustc will inline kasan operations,
but the kasan shadow offset is not specified, which leads to the inlined
kasan instructions being incorrect.
Note that the -Zsanitizer=kernel-hwaddress parameter itself does not
lead to a rustc-option failure despite being aarch64-specific because
RUSTFLAGS_KASAN has not yet been added to KBUILD_RUSTFLAGS when
rustc-option is evaluated by the kasan Makefile.
Cc: [email protected]
Fixes: 46e24a545c ("rust: kasan/kbuild: fix missing flags on first build")
Signed-off-by: Alice Ryhl <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ Edited slightly:
- Reset variable to avoid using the environment.
- Use a simply expanded variable flavor for simplicity.
- Export variable so that behavior in sub-`make`s is consistent.
This matches other variables. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
It turns out that there are BPF use cases that rely on nesting RCU
Tasks Trace readers. These use cases are well-served by the old
rcu_read_lock_trace() and rcu_read_unlock_trace() functions that maintain
a nesting counter in the task_struct structure. But these use cases incur
a performance penalty when using the shiny new rcu_read_lock_tasks_trace()
and rcu_read_unlock_tasks_trace() functions, which nest in the same way
that SRCU does.
This means that rcu_read_lock_trace() and rcu_read_unlock_trace()
will be with us for some time. Therefore, remove the checkpatch.pl
deprecation.
Also, the rcu_read_lock_tasks_trace() and rcu_read_unlock_tasks_trace()
functions are intended for use only by BPF. Therefore, add them to
the list of functions that checkpatch complains about outside of BPF
(and of course, RCU).
Reported-by: Puranjay Mohan <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>
Cc: Andy Whitcroft <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Dwaipayan Ray <[email protected]>
Cc: Lukas Bulwahn <[email protected]>
Signed-off-by: Uladzislau Rezki (Sony) <[email protected]>
Verify that SPDX-License-Identifier headers at the top of source files
are parsed correctly.
Assisted-by: Cursor:claude-sonnet-4-5
Assisted-by: OpenCode:GLM-4-7
Co-developed-by: Maximilian Huber <[email protected]>
Signed-off-by: Maximilian Huber <[email protected]>
Signed-off-by: Luis Augenstein <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Implement the SPDX build graph to describe the relationships
between source files in the source SBOM and output files in
the output SBOM.
Assisted-by: Cursor:claude-sonnet-4-5
Assisted-by: OpenCode:GLM-4-7
Co-developed-by: Maximilian Huber <[email protected]>
Signed-off-by: Maximilian Huber <[email protected]>
Signed-off-by: Luis Augenstein <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Implement the SPDX source graph which contains all source files
involved during the build, along with the licensing information
for each file.
Assisted-by: Cursor:claude-sonnet-4-5
Assisted-by: OpenCode:GLM-4-7
Co-developed-by: Maximilian Huber <[email protected]>
Signed-off-by: Maximilian Huber <[email protected]>
Signed-off-by: Luis Augenstein <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Implement the SPDX output graph which contains the distributable
build outputs and high level metadata about the build.
Assisted-by: Cursor:claude-sonnet-4-5
Assisted-by: OpenCode:GLM-4-7
Co-developed-by: Maximilian Huber <[email protected]>
Signed-off-by: Maximilian Huber <[email protected]>
Signed-off-by: Luis Augenstein <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Implement the kernel_file module that collects file metadata,
including license identifier for source files, SHA-256 hash,
Git blob object ID, an estimation of the file type, and
whether files belong to the source, build, or output SBOM.
Assisted-by: Cursor:claude-sonnet-4-5
Assisted-by: OpenCode:GLM-4-7
Co-developed-by: Maximilian Huber <[email protected]>
Signed-off-by: Maximilian Huber <[email protected]>
Signed-off-by: Luis Augenstein <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Implement shared SPDX elements used in all three documents.
Assisted-by: Cursor:claude-sonnet-4-5
Assisted-by: OpenCode:GLM-4-7
Co-developed-by: Maximilian Huber <[email protected]>
Signed-off-by: Maximilian Huber <[email protected]>
Signed-off-by: Luis Augenstein <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Add infrastructure to serialize an SPDX graph as a JSON-LD
document. NamespaceMaps in the SPDX document are converted
to custom prefixes in the @context field of the JSON-LD output.
The SBOM tool uses NamespaceMaps solely to shorten SPDX IDs,
avoiding repetition of full namespace URIs by using short prefixes.
Assisted-by: Cursor:claude-sonnet-4-5
Assisted-by: OpenCode:GLM-4-7
Co-developed-by: Maximilian Huber <[email protected]>
Signed-off-by: Maximilian Huber <[email protected]>
Signed-off-by: Luis Augenstein <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Implement Python dataclasses to model the SPDX classes
required within an SPDX document. The class and property
names are consistent with the SPDX 3.0.1 specification.
Assisted-by: Cursor:claude-sonnet-4-5
Assisted-by: OpenCode:GLM-4-7
Co-developed-by: Maximilian Huber <[email protected]>
Signed-off-by: Maximilian Huber <[email protected]>
Signed-off-by: Luis Augenstein <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Implement command graph generation by parsing .cmd files to build a
dependency graph.
Add CmdGraph, CmdGraphNode, and .cmd file parsing.
Supports generating a flat list of used source files via the
--generate-used-files cli argument.
Assisted-by: Cursor:claude-sonnet-4-5
Assisted-by: OpenCode:GLM-4-7
Co-developed-by: Maximilian Huber <[email protected]>
Signed-off-by: Maximilian Huber <[email protected]>
Signed-off-by: Luis Augenstein <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Add logging infrastructure for warnings and errors.
Errors and warnings are accumulated and summarized in the end.
Assisted-by: Cursor:claude-sonnet-4-5
Assisted-by: OpenCode:GLM-4-7
Co-developed-by: Maximilian Huber <[email protected]>
Signed-off-by: Maximilian Huber <[email protected]>
Signed-off-by: Luis Augenstein <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Pull Kbuild fixes from Nicolas Schier:
- modpost: prevent stack buffer overflow in do_input_entry() and
do_dmi_entry()
Defensively replace unbound sprintf() calls in file2alias to prevent
silent stack overflows and detect alias name overflows with proper
error message.
- kbuild: pacman-pkg: make "rc" releases adhere to pacman versioning
scheme
Enable smooth upgrades from "rc" releases w/ pacman packages.
* tag 'kbuild-fixes-7.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux:
kbuild: pacman-pkg: make "rc" releases adhere to pacman versioning scheme
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Pull misc fixes from Andrew Morton:
"14 hotfixes. 9 are for MM. 10 are cc:stable and the remainder are for
post-7.1 issues or aren't deemed suitable for backporting.
There's a two-patch MAINTAINERS series from Mike Rapoport which
updates us for the new KEXEC/KDUMP/crash/LUO/etc arrangements. And
another two-patch series from Muchun Song to fix a couple of
memory-hotplug issues. Otherwise singletons, please see the changelogs
for details"
* tag 'mm-hotfixes-stable-2026-05-18-21-07' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
mm/memory: fix spurious warning when unmapping device-private/exclusive pages
mm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special()
drivers/base/memory: fix memory block reference leak in poison accounting
mm/memory_hotplug: fix memory block reference leak on remove
lib: kunit_iov_iter: fix test fail on powerpc
mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free
MAINTAINERS: add kexec@ list to LIVE UPDATE ENTRY
MAINTAINERS: add tree for KDUMP and KEXEC
selftests/mm: run_vmtests.sh: fix destructive tests invocation
scripts/gdb: slab: update field names of struct kmem_cache
scripts/gdb: mm: cast untyped symbols in x86_page_ops
mm/damon: fix damos_stat tracepoint format for sz_applied
mm/damon/sysfs-schemes: call missing mem_cgroup_iter_break()
mm/migrate_device: fix spinlock leak in migrate_vma_insert_huge_pmd_page
The package versioning scheme does not enable smooth upgrades from "rc"
releases to the corresponding stable releases (e.g. 7.0.0-rc7 -> 7.0.0)
because pacman considers that a downgrade due to the underscore in
pkgver (e.g. 7.0.0_rc7), see e.g. vercmp(8) for an explanation of the
package version comparison used by pacman. Package versions which are
derived from said releases (e.g. built from git revisions) are
similarly affected. Fix this by modifying pkgver in order to remove the
hyphen from kernel versions containing "-rcN", where N is a
non-negative integer.
Acked-by: Thomas Weißschuh <[email protected]>
Signed-off-by: Viktor Jägersküpper <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>
Link: https://patch.msgid.link/[email protected]
Fixes: c8578539de ("kbuild: add script and target to generate pacman package")
Signed-off-by: Nicolas Schier <[email protected]>
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Signed-off-by: Hasan Basbunar <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Nicolas Schier <[email protected]>
For gcc-16, the CONST_CAST macro family was removed. Add back what
we were using in gcc-common.h, as they are simple wrappers.
See GCC commits:
c3d96ff9e916c02584aa081f03ab999292efbb50
458c7926d48959abcb2c1adaa22458e27459a551
Suggested-by: Ingo Saitz <[email protected]>
Link: https://lore.kernel.org/lkml/[email protected]
Fixes: 6b90bd4ba4 ("GCC plugin infrastructure")
Tested-by: Ivan Bulatovic <[email protected]>
Tested-by: Christopher Cradock <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
The commit 5ba6bc27b1 ("slab: decouple pointer to barn from
kmem_cache_node") reorganized the struct kmem_cache to factor out the
per-node fields to the new struct kmem_cache_per_node_ptrs. This causes
the gdb scripts for lx-slabinfo and lx-slabtrace fail as they still
reference the old structure.
Adjust the gdb scripts to match the current state of struct kmem_cache.
Link: https://lore.kernel.org/[email protected]
Fixes: 5ba6bc27b1 ("slab: decouple pointer to barn from kmem_cache_node")
Signed-off-by: Illia Ostapyshyn <[email protected]>
Acked-by: Harry Yoo (Oracle) <[email protected]>
Acked-by: Vlastimil Babka (SUSE) <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: Hao Li <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Seongjun Hong <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Introduce a script that provides a simple ascii representation of the
timer migration tree on top of boot trace events.
First boot with:
trace_event==tmigr_connect_cpu_parent,tmigr_connect_child_parent
Then parse the result with:
scripts/timer_migration_tree.py < /sys/kernel/tracing/trace
On a system with 8 CPUs, this produces the following output:
Tree for capacity 1024
/-0, node 0, lvl:-1
|
|--1, node 0, lvl:-1
|
|--2, node 0, lvl:-1
|
|--3, node 0, lvl:-1
-- /00000000dcebac8b, node 0, lvl:0
|--4, node 0, lvl:-1
|
|--5, node 0, lvl:-1
|
|--6, node 0, lvl:-1
|
\-7, node 0, lvl:-1
Signed-off-by: Frederic Weisbecker <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://patch.msgid.link/[email protected]
For all CONFIG_CFI+CONFIG_CALL_PADDING configs, for C functions, the
__cfi_ symbols only cover the 5-byte kCFI type hash. After that there
also N bytes of NOP padding between the hash and the function entry
which aren't associated with any symbol.
The NOPs can be replaced with actual code at runtime. Without a symbol,
unwinders and tooling have no way of knowing where those bytes belong.
Grow the existing __cfi_* symbols to fill that gap.
Note that assembly functions with SYM_TYPED_FUNC_START() aren't affected
by this issue, their __cfi_ symbols also cover the padding.
Also, CONFIG_PREFIX_SYMBOLS has no reason to exist: CONFIG_CALL_PADDING
is what causes the compiler to emit NOP padding before function entry
(via -fpatchable-function-entry), so it's the right condition for
creating prefix symbols.
Remove CONFIG_PREFIX_SYMBOLS, as it's no longer needed. Simplify the
LONGEST_SYM_KUNIT_TEST dependency accordingly. Rework objtool's
arguments a bit to handle the variety of prefix/cfi-related cases.
Suggested-by: Peter Zijlstra <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
The --short-circuit option implicitly requires that certain directories
are already in klp-tmp. Enforce that to prevent confusing errors.
Acked-by: Song Liu <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
The checksum functionality has been moved to "objtool klp checksum"
which is now used by klp-build. Remove the now-dead --checksum and
--debug-checksum options from the default objtool command.
Acked-by: Song Liu <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Use the new "objtool klp checksum" subcommand instead of injecting
--checksum into every objtool invocation via OBJTOOL_ARGS during the
kernel build.
This decouples checksum generation from the build, running it in
separate post-build passes, making the code (and the patch generation
pipeline itself) more modular.
Acked-by: Song Liu <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
SRC and OBJ are both set to $(pwd) and are always identical. The script
already enforces that klp-build runs from the kernel root directory, and
builds are done in-place, making these variables unnecessary.
Suggested-by: Song Liu <[email protected]>
Acked-by: Song Liu <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Print the full objtool command line when '--verbose' is given to help
with debugging.
Acked-by: Song Liu <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Realmode code is compiled as a separate 16-bit binary and embedded into
the kernel image via rmpiggy.S. It can't be livepatched.
Acked-by: Song Liu <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
vDSO code runs in userspace and can't be livepatched. Such patches also
cause spurious "new function" errors due to generated files like
vdso*-image.c having unstable line numbers across builds.
Acked-by: Song Liu <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
If a build error occurs and the user hits Ctrl-C while a large patch is
being reverted during cleanup, the cleanup EXIT trap gets re-triggered
and tries to re-revert the already partially-reverted patch. That
causes 'patch -R' to repeatedly prompt
"Unreversed patch detected! Ignore -R? [n]"
for each already-reverted hunk, with no way to break out.
Fix it by adding '--force' to the patch revert command in
revert_patch(), which causes it to silently ignore already-reverted
hunks. And ignore errors, as the cleanup is always best-effort.
For similar reasons, add to APPLIED_PATCHES before (rather than after)
applying the patch in apply_patch() so an interrupted apply will also
get cleaned up.
Fixes: d36a7343f4 ("livepatch/klp-build: switch to GNU patch and recountdiff")
Acked-by: Song Liu <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
When a patch applies with fuzz, the detailed output from the patch tool
can be very noisy, especially for big patches.
Suppress the fuzz details by default, while keeping the "applied with
fuzz" warning. The noise can be restored with '--verbose'.
Acked-by: Song Liu <[email protected]>
Reviewed-by: Miroslav Benes <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Make sure all patch files actually exist. Otherwise there can be
confusing errors later.
Acked-by: Song Liu <[email protected]>
Reviewed-by: Miroslav Benes <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
The errtrace option (combined with the ERR trap) already serves the same
function (and more) as errexit, so errexit is redundant. And it has
more pitfalls. Remove it.
Acked-by: Song Liu <[email protected]>
Reviewed-by: Miroslav Benes <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
The klp-build -f/--show-first-changed feature uses diff to compare
checksum log lines between original and patched objects. However, diff
compares entire lines, including the offset field. When a function is
at a different section offset, the offset field differs even though the
instruction checksum is identical, causing the wrong instruction to be
printed.
Only compare the checksum field when looking for the first changed
instruction. Also print both the original and patched offsets when they
differ.
Fixes: 78be9facfb ("livepatch/klp-build: Add --show-first-changed option to show function divergence")
Acked-by: Song Liu <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
If .config is out of date with the kernel source, 'make syncconfig'
hangs while waiting for user input on new config options. Detect the
mismatch and return an error.
Fixes: 6f93f7b068 ("livepatch/klp-build: Fix inconsistent kernel version")
Acked-by: Song Liu <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Some architectures link libgcc.a from the toolchain into the kernel.
gen_compile_commands trie to read the kbuild .cmd files of its
constituent object files, which are not available.
Flat out ignore libgcc.a, as it is not built as part of the kernel
anyways.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Thomas Weißschuh <[email protected]>
Acked-by: Nathan Chancellor <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
Yafang Shao