FIT (Flat Image Tree) allows a ramdisk to be included in each
configuration. Add support for this to the script.
This feature is not available via 'make image.fit' since the ramdisk
likely needs to be built separately anyway, e.g. using modules from
the kernel build. Future work may provide support for doing that.
Note that the uncompressed size is not correct when a ramdisk is used,
since it is too expensive to decompress the ramdisk.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://patch.msgid.link/20260106162738.2605574-3-sjg@chromium.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Allow ML-DSA module signing to be enabled.
Note that OpenSSL's CMS_*() function suite does not, as of OpenSSL-3.6,
support the use of CMS_NOATTR with ML-DSA, so the prohibition against using
signedAttrs with module signing has to be removed. The selected digest
then applies only to the algorithm used to calculate the digest stored in
the messageDigest attribute. The OpenSSL development branch has patches
applied that fix this[1], but it appears that that will only be available
in OpenSSL-4.
[1] https://github.com/openssl/openssl/pull/28923
sign-file won't set CMS_NOATTR if openssl is earlier than v4, resulting in
the use of signed attributes.
The ML-DSA algorithm takes the raw data to be signed without regard to what
digest algorithm is specified in the CMS message. The CMS specified digest
algorithm is ignored unless signedAttrs are used; in such a case, only
SHA512 is permitted.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jarkko Sakkinen <jarkko@kernel.org>
cc: Eric Biggers <ebiggers@kernel.org>
cc: Lukas Wunner <lukas@wunner.de>
cc: Ignat Korchagin <ignat@cloudflare.com>
cc: Stephan Mueller <smueller@chronox.de>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: keyrings@vger.kernel.org
cc: linux-crypto@vger.kernel.org
Pull objtool fixes from Ingo Molnar:
- Fix a build error on ia32-x86_64 cross builds
- Replace locally open coded ALIGN_UP(), ALIGN_UP_POW2()
and MAX(), which, beyond being duplicates, the
ALIGN_UP_POW2() is also buggy
- Fix objtool klp-diff regression caused by a recent
change to the bug table format
- Fix klp-build vs CONFIG_MODULE_SRCVERSION_ALL build
failure
* tag 'objtool-urgent-2026-02-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
livepatch/klp-build: Fix klp-build vs CONFIG_MODULE_SRCVERSION_ALL
objtool/klp: Fix bug table handling for __WARN_printf()
objtool: Replace custom macros in elf.c with shared ones
objtool: Print bfd_vma as unsigned long long on ia32-x86_64 cross build
__noinstr_text_start is adding noise to the script, ignore it.
For instance using __always_inline on __skb_incr_checksum_unnecessary and
CC=clang build.
Before this patch, __noinstr_text_start can show up and confuse us.
$ scripts/bloat-o-meter -t vmlinux.old vmlinux.new
add/remove: 0/2 grow/shrink: 3/0 up/down: 212/-206 (6)
Function old new delta
tcp6_gro_complete 208 283 +75
tcp4_gro_complete 376 449 +73
__noinstr_text_start 3536 3600 +64
__pfx___skb_incr_checksum_unnecessary 32 - -32
__skb_incr_checksum_unnecessary 174 - -174
Total: Before=25509464, After=25509470, chg +0.00%
After this patch we have a more precise result.
$ scripts/bloat-o-meter -t vmlinux.old vmlinux.new
add/remove: 0/2 grow/shrink: 2/0 up/down: 148/-206 (-58)
Function old new delta
tcp6_gro_complete 208 283 +75
tcp4_gro_complete 376 449 +73
__pfx___skb_incr_checksum_unnecessary 32 - -32
__skb_incr_checksum_unnecessary 174 - -174
Total: Before=25505928, After=25505870, chg -0.00%
Link: https://lkml.kernel.org/r/20260117083448.3877418-1-edumazet@google.com
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Pull Kbuild fixes from Nicolas Schier:
- Generate rpm-pkg debuginfo package manually, allowing signed kernel
modules in rpm package, again
- Fix permissions of modules.builtin.modinfo
- Do not run kernel-doc when building external modules
* tag 'kbuild-fixes-6.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux:
kbuild: Do not run kernel-doc when building external modules
kbuild: Fix permissions of modules.builtin.modinfo
kbuild: rpm-pkg: Generate debuginfo package manually
After commit 778b8ebe51 ("docs: Move the python libraries to
tools/lib/python"), building an external module with any value of W=
against the output of install-extmod-build fails with:
$ make -C /usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build M=$PWD W=1
make: Entering directory '/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build'
make[1]: Entering directory '...'
CC [M] ...
Traceback (most recent call last):
File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 339, in <module>
main()
~~~~^^
File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 295, in main
from kdoc.kdoc_files import KernelFiles # pylint: disable=C0415
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ModuleNotFoundError: No module named 'kdoc'
scripts/lib was included in the build directory from find_in_scripts but
after the move to tools/lib/python, it is no longer included, breaking
kernel-doc.py.
Commit eba6ffd126 ("docs: kdoc: move kernel-doc to tools/docs") breaks
this even further by moving kernel-doc outside of scripts as well, so it
cannot be found when called by cmd_checkdoc.
$ make -C /usr/lib/modules/6.19.0-rc7-next-20260130/build M=$PWD W=1
make: Entering directory '/usr/lib/modules/6.19.0-rc7-next-20260130/build'
make[1]: Entering directory '...'
CC [M] ...
python3: can't open file '/usr/lib/modules/6.19.0-rc7-next-20260130/build/tools/docs/kernel-doc': [Errno 2] No such file or directory
While kernel-doc could be useful for external modules, it is more useful
for in-tree documentation that will be build and included in htmldocs.
Rather than including it in install-extmod-build, just skip running
kernel-doc for the external module build.
Cc: stable@vger.kernel.org
Fixes: 778b8ebe51 ("docs: Move the python libraries to tools/lib/python")
Reported-by: Rong Zhang <i@rong.moe>
Closes: https://lore.kernel.org/20260129175321.415295-1-i@rong.moe/
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260130-kbuild-skip-kernel-doc-extmod-v1-1-58443d60131a@kernel.org
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Signed-off-by: Nicolas Schier <nsc@kernel.org>
Pull Rust fixes from Miguel Ojeda:
"Toolchain and infrastructure:
- Trigger rebuilds of the newly added 'proc-macro2' crate (and its
dependencies) when the Rust compiler version changes
- Fix error in '.rsi' targets (macro expanding single targets) under
'O=' pointing to an external (not subdir) folder
- Fix off-by-one line number in 'rustdoc' KUnit tests
- Add '-fdiagnostics-show-context' to GCC flags skipped by 'bindgen'
- Clean objtool warning by adding one more 'noreturn' function
- Clean 'libpin_init_internal.{so,dylib}' in 'mrproper'
'kernel' crate:
- Fix build error when using expressions in formatting arguments
- Mark 'num::Bounded::__new()' as unsafe and clean documentation
accordingly
- Always inline functions using 'build_assert' with arguments
- Fix 'rusttest' build error providing the right 'isize_atomic_repr'
type for the host
'macros' crate:
- Fix 'rusttest' build error by ignoring example
rust-analyzer:
- Remove assertion that was not true for distributions like NixOS
- Add missing dependency edges and fix editions for 'quote' and
sysroot crates to provide correct IDE support
DRM Tyr:
- Fix build error by adding missing dependency on 'CONFIG_COMMON_CLK'
Plus clean a few typos in docs and comments"
* tag 'rust-fixes-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (28 commits)
rust: num: bounded: clean __new documentation and comments
scripts: generate_rust_analyzer: fix resolution of #[pin_data] macros
drm/tyr: depend on `COMMON_CLK` to fix build error
rust: sync: atomic: Provide stub for `rusttest` 32-bit hosts
kbuild: rust: clean libpin_init_internal in mrproper
rust: proc-macro2: rebuild if the version text changes
rust: num: bounded: add missing comment for always inlined function
rust: sync: refcount: always inline functions using build_assert with arguments
rust: bits: always inline functions using build_assert with arguments
scripts: generate_rust_analyzer: compile sysroot with correct edition
scripts: generate_rust_analyzer: compile quote with correct edition
scripts: generate_rust_analyzer: quote: treat `core` and `std` as dependencies
scripts: generate_rust_analyzer: syn: treat `std` as a dependency
scripts: generate_rust_analyzer: remove sysroot assertion
rust: kbuild: give `--config-path` to `rustfmt` in `.rsi` target
scripts: generate_rust_analyzer: Add pin_init_internal deps
scripts: generate_rust_analyzer: Add pin_init -> compiler_builtins dep
scripts: generate_rust_analyzer: Add compiler_builtins -> core dep
rust: macros: ignore example with module parameters
rust: num: bounded: mark __new as unsafe
...
There are no entries left to ignore and none should be added again.
Remove the now unused logic.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
UAPI headers are not supposed to leak references to kconfig symbols.
These won't be set when building userspace. Hide the kconfig reference
behind 'if defined(__KERNEL__)', so it will be stripped by
headers_install.sh. The result for userspace will be the same, but the
exceptions in headers_install.sh can also be removed.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
UAPI headers are not supposed to leak references to kconfig symbols.
They are undefined there in any case. As all actual definitions of this
header are guarded behind a kconfig symbol, for userspace the header is
always identical to its asm-generic variant.
Make the custom UAPI header a kernel-internal one, so the leaks of
kconfig symbols are fixed and userspace will instead use
asm-generic/swab.h directly.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/lkml/93c55086-931a-4282-a94c-de4954047fa9@app.fastmail.com/
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Some special sections specify their ELF section entsize, for example:
.pushsection section, "M", @progbits, 8
The entsize (8 in this example) is needed by objtool klp-diff for
extracting individual entries.
Clang assembler versions older than 20 silently ignore the above
construct and set entsize to 0, resulting in the following error:
.discard.annotate_data: missing special section entsize or annotations
Add a klp-build check to prevent the use of Clang assembler versions
prior to 20.
Fixes: 24ebfcd65a ("livepatch/klp-build: Introduce klp-build script for generating livepatch modules")
Reported-by: Song Liu <song@kernel.org>
Acked-by: Song Liu <song@kernel.org>
Link: https://patch.msgid.link/957fd52e375d0e2cfa3ac729160da995084a7f5e.1769562556.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Currently, cacheline group macros trigger checkpatch warnings.
For example:
$ ./scripts/checkpatch.pl -g ba7e025a6c84aed012421468d83639e5dae982b0
WARNING: Missing a blank line after declarations
#58: FILE: drivers/gpio/gpio-virtio.c:32:
+ struct virtio_gpio_response res;
+ __dma_from_device_group_end();
$ ./scripts/checkpatch.pl -g 5d4cc87414
WARNING: Missing a blank line after declarations
#267: FILE: include/net/sock.h:431:
+ int sk_rcvlowat;
+ __cacheline_group_end(sock_read_rx);
But these are not actually statements - the following macros
all expand to zero-length fields:
__cacheline_group_begin()
__cacheline_group_end()
__cacheline_group_begin_aligned()
__cacheline_group_end_aligned()
__dma_from_device_group_begin()
__dma_from_device_group_end()
Add them to $declaration_macros so checkpatch recognizes this fact.
Message-ID: <b345bb7e2d4e23672e3e5d1b283754dc11c7d8cd.1767647872.git.mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Currently, modules.builtin.modinfo is created with executable permissions
(0755). This is because after commit 39cfd5b121 ("kbuild: extract
modules.builtin.modinfo from vmlinux.unstripped"), modules.builtin.modinfo
is extracted from vmlinux.unstripped using objcopy. When extracting
sections, objcopy inherits attributes from the source ELF file.
Since modules.builtin.modinfo is a data file and not an executable,
it should have regular file permissions (0644). The executable bit
can trigger warnings in Debian's Lintian tool.
Explicitly remove the executable bit after generation.
Fixes: 39cfd5b121 ("kbuild: extract modules.builtin.modinfo from vmlinux.unstripped")
Signed-off-by: Ethan Zuo <yuxuan.zuo@outlook.com>
Link: https://patch.msgid.link/SY0P300MB0609F6916B24ADF65502940B9C91A@SY0P300MB0609.AUSP300.PROD.OUTLOOK.COM
Signed-off-by: Nicolas Schier <nsc@kernel.org>
Pull pin-init updates from Benno Lossin:
"Added:
- Implement 'InPlaceWrite' for '&'static mut MaybeUninit<T>'. This
enables users to use external allocation mechanisms such as
'static_cell'.
- Add Gary Guo as a Maintainer.
Changed:
- Rewrote all proc-macros ('[pin_]init!', '#[pin_data]',
'#[pinned_drop]', 'derive([Maybe]Zeroable)'), using 'syn' with
better diagnostics.
- Support tuple structs in 'derive([Maybe]Zeroable)'.
- Support attributes on fields in '[pin_]init!' (such as
'#[cfg(...)]').
- Add a '#[default_error(<type>)]' attribute to '[pin_]init!' to
override the default error (when no '? Error' is specified).
- Support packed structs in '[pin_]init!' with
'#[disable_initialized_field_access]'.
Removed:
- Remove 'try_[pin_]init!' in favor of merging their feature
with '[pin_]init!'. Update the kernel's own 'try_[pin_]init!'
macros to use the 'default_error' attribute.
Fixed:
- Correct 'T: Sized' bounds to 'T: ?Sized' in the generated
'PinnedDrop' check by '#[pin_data]'."
* tag 'pin-init-v7.0' of https://github.com/Rust-for-Linux/linux:
rust: pin-init: Implement `InPlaceWrite<T>` for `&'static mut MaybeUninit<T>`
MAINTAINERS: add Gary Guo to pin-init
rust: pin-init: internal: init: simplify Zeroable safety check
rust: pin-init: internal: init: add escape hatch for referencing initialized fields
rust: pin-init: internal: init: add support for attributes on initializer fields
rust: init: use `#[default_error(err)]` for the initializer macros
rust: pin-init: add `#[default_error(<type>)]` attribute to initializer macros
rust: pin-init: rewrite the initializer macros using `syn`
rust: pin-init: add `?Sized` bounds to traits in `#[pin_data]` macro
rust: pin-init: rewrite `#[pin_data]` using `syn`
rust: pin-init: rewrite the `#[pinned_drop]` attribute macro using `syn`
rust: pin-init: rewrite `derive(Zeroable)` and `derive(MaybeZeroable)` using `syn`
rust: pin-init: internal: add utility API for syn error handling
rust: pin-init: add `syn` dependency and remove `proc-macro[2]` and `quote` workarounds
rust: pin-init: allow the crate to refer to itself as `pin-init` in doc tests
rust: pin-init: remove `try_` versions of the initializer macros
When building a patch to a single-file kernel module with
CONFIG_MODULE_SRCVERSION_ALL enabled, the klp-build module link fails in
modpost:
Diffing objects
drivers/md/raid0.o: changed function: raid0_run
Building patch module: livepatch-0001-patch-raid0_run.ko
drivers/md/raid0.c: No such file or directory
...
The problem here is that klp-build copied drivers/md/.raid0.o.cmd to the
module build directory, but it didn't also copy over the input source
file listed in the .cmd file:
source_drivers/md/raid0.o := drivers/md/raid0.c
So modpost dies due to the missing .c file which is needed for
calculating checksums for CONFIG_MODULE_SRCVERSION_ALL.
Instead of copying the original .cmd file, just create an empty one.
Modpost only requires that it exists. The original object's build
dependencies are irrelevant for the frankenobjects used by klp-build.
Fixes: 24ebfcd65a ("livepatch/klp-build: Introduce klp-build script for generating livepatch modules")
Reported-by: Song Liu <song@kernel.org>
Tested-by: Song Liu <song@kernel.org>
Link: https://patch.msgid.link/c41b6629e02775e4c1015259aa36065b3fe2f0f3.1769471792.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Pull tracing fixes from Steven Rostedt:
- Fix a crash with passing a stacktrace between synthetic events
A synthetic event is an event that combines two events into a single
event that can display fields from both events as well as the time
delta that took place between the events. It can also pass a
stacktrace from the first event so that it can be displayed by the
synthetic event (this is useful to get a stacktrace of a task
scheduling out when blocked and recording the time it was blocked
for).
A synthetic event can also connect an existing synthetic event to
another event. An issue was found that if the first synthetic event
had a stacktrace as one of its fields, and that stacktrace field was
passed to the new synthetic event to be displayed, it would crash the
kernel. This was due to the stacktrace not being saved as a
stacktrace but was still marked as one. When the stacktrace was read,
it would try to read an array but instead read the integer metadata
of the stacktrace and dereferenced a bad value.
Fix this by saving the stacktrace field as a stacktrace.
- Fix possible overflow in cmp_mod_entry() compare function
A binary search is used to find a module address and if the addresses
are greater than 2GB apart it could lead to truncation and cause a
bad search result. Use normal compares instead of a subtraction
between addresses to calculate the compare value.
- Fix output of entry arguments in function graph tracer
Depending on the configurations enabled, the entry can be two
different types that hold the argument array. The macro
FGRAPH_ENTRY_ARGS() is used to find the correct arguments from the
given type. One location was missed and still referenced the
arguments directly via entry->args and could produce the wrong value
depending on how the kernel was configured.
- Fix memory leak in scripts/tracepoint-update build tool
If the array fails to allocate, the memory for the values needs to be
freed and was not. Free the allocated values if the array failed to
allocate.
* tag 'trace-v6.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
scripts/tracepoint-update: Fix memory leak in add_string() on failure
function_graph: Fix args pointer mismatch in print_graph_retval()
tracing: Avoid possible signed 64-bit truncation
tracing: Fix crash on synthetic stacktrace field usage
When realloc() fails in add_string(), the function returns -1 but leaves
*vals pointing to the previously allocated memory. This can cause memory
leaks in callers like make_trace_array() that return on error without
freeing the partially built array.
Fix this by freeing *vals and setting it to NULL when realloc() fails.
This makes the error handling self-contained in add_string() so callers
don't need to handle cleanup on failure.
This bug is found by my static analysis tool and my code review.
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fixes: e30f8e61e2 ("tracing: Add a tracepoint verification check at build time")
Link: https://patch.msgid.link/20260119114542.1714405-1-geoffreyhe2@gmail.com
Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Converting from shell/sed/grep loop to awk improves runtime
checks of Yocto genericarm64 kernel config from 20 seconds
to under 1 second. The checks catch this kind of issues:
WARNING: CONFIG_BLK_DEV_DM differs:
Requested value: CONFIG_BLK_DEV_DM=y
Actual value: CONFIG_BLK_DEV_DM=m
WARNING: CONFIG_SECURITY_NETWORK differs:
Requested value: CONFIG_SECURITY_NETWORK=n
Actual value: CONFIG_SECURITY_NETWORK=y
WARNING: Value requested for CONFIG_ARM64_BTI_KERNEL not in final .config
Requested value: CONFIG_ARM64_BTI_KERNEL=y
Actual value:
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Link: https://patch.msgid.link/20260122105751.2186609-2-mikko.rapeli@linaro.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
merge_config.sh shell/sed/grep loop scales poorly and is slow.
With Yocto genericarm64 kernel and around 190 config fragments
the script takes more than 20 minutes to run on a fast build machine.
Re-implementation with awk does the same job in 10 seconds.
Using awk since it is likely available in the build environments
and using perl, python etc would introduce more complex runtime
dependencies. awk is good enough and lot better than shell/sed/grep.
Output stays the same but changed execution time means that
parallel job output may be ordered differently.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Link: https://patch.msgid.link/20260122105751.2186609-1-mikko.rapeli@linaro.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
When the kallsyms relative base was introduced, per-CPU variable
references on x86_64 SMP were implemented as offsets into the respective
per-CPU region, rather than offsets relative to the location of the
variable's template in the kernel image, which is how other
architectures implement it.
This required kallsyms to reason about the difference between the two,
and the sign of the value in the kallsyms_offsets[] array was used to
distinguish them. This meant that negative offsets were not permitted
for ordinary variables, and so it was crucial that the relative base was
chosen such that all offsets were positive numbers.
This is no longer needed: instead, the offsets can simply be encoded as
values in the range -/+ 2 GiB, which is precisely what PC32 relocations
provide on most architectures. So it is possible to simplify the logic,
and just use _text as the anchor directly, and let the linker calculate
the final value based on the location of the entry itself.
Some architectures (nios2, extensa) do not support place-relative
relocations at all, but these are all 32-bit and non-relocatable, and so
there is no need for place-relative relocations in the first place, and
the actual symbol values can just be stored directly.
This makes all entries in the kallsyms_offsets[] array visible as
place-relative references in the ELF metadata, which will be important
when implementing ELF-based fg-kaslr.
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260116093359.2442297-6-ardb+git@google.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Provide a new syscall which has the only purpose to yield the CPU after the
kernel granted a time slice extension.
sched_yield() is not suitable for that because it unconditionally
schedules, but the end of the time slice extension is not required to
schedule when the task was already preempted. This also allows to have a
strict check for termination to catch user space invoking random syscalls
including sched_yield() from a time slice extension region.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251215155708.929634896@linutronix.de
Some folks evidently have muscle memory expecting kernel-doc to be under
scripts/. Now that we have moved it to tools/docs, leave behind a symbolic
link to reduce the global profanity count.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
There are some typos and English errors in the comments of kernel‑doc.py.
Locate them with the help of an LLM (gpt‑oss 14B), executed locally
with this prompt:
review English grammar and syntax at the comments on the code below:
<cat scripts/kernel-doc.py>
While LLM worked fine for the task of doing an English grammar review
for strings, being able to distinguish them from the actual code, it
was not is perfect: some things required manual work to fix.
-
While here, replace:
"/**" with: ``/**``
As, if we ever rename this script to kernel_doc.py and add it to
Sphinx ext autodoc, we want to avoid this warning:
scripts/kernel_doc.py:docstring of kernel_doc:10: WARNING: Inline strong start-string without end-string. [docutils]
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <ec08727f22ad35e6c58519c1f425f216f14b701c.1768823489.git.mchehab+huawei@kernel.org>
Fix the `generate_rust_analyzer.py` script to ensure that the
`rust-project.json` it produces includes `core` and `std` in the `deps`
field for the `quote` crate.
`quote` directly references items from both `core` and `std`, so
rust-analyzer should treat them as dependencies to provide correct IDE
support.
For example, the `::quote::ToTokens` trait is implemented for
`std::ffi::CString`. With `std` listed in the `deps` field,
rust-analyzer can show the expected autocomplete for the
`::quote::ToTokens` methods on `std::ffi::CString`.
Verified the explicit uses of `core` and `std` using:
grep -rnE 'core::|std::' rust/quote/
Fixes: 88de91cc1c ("rust: quote: enable support in kbuild")
Signed-off-by: Jesung Yang <y.j3ms.n@gmail.com>
Reviewed-by: Tamir Duberstein <tamird@gmail.com>
Link: https://patch.msgid.link/cef76fc1105481d219953c8552eb5eb07dac707a.1764062688.git.y.j3ms.n@gmail.com
[ Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Fix the `generate_rust_analyzer.py` script to ensure that the
`rust-project.json` it produces includes `std` in the `deps` field for
the `syn` crate.
`syn` directly references items from `std`, so rust-analyzer should
treat it as a dependency to provide correct IDE support.
For example, `syn::Punctuated` contains fields of type `Vec<..>` and
`Option<..>`, both of which come from the standard library prelude.
With `std` listed in the `deps` field, rust-analyzer can infer the types
of these fields instead of showing `{unknown}`.
Verified the explicit uses of `std` using:
grep -rn 'std::' rust/syn/
Fixes: 737401751a ("rust: syn: enable support in kbuild")
Signed-off-by: Jesung Yang <y.j3ms.n@gmail.com>
Reviewed-by: Tamir Duberstein <tamird@gmail.com>
Tested-by: Tamir Duberstein <tamird@gmail.com>
Link: https://patch.msgid.link/6dbdf6e1c1639ae381ca9ab7041f84728ffa2267.1764062688.git.y.j3ms.n@gmail.com
[ Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
`rustfmt` is configured via the `.rustfmt.toml` file in the source tree,
and we apply `rustfmt` to the macro expanded sources generated by the
`.rsi` target.
However, under an `O=` pointing to an external folder (i.e. not just
a subdir), `rustfmt` will not find the file when checking the parent
folders. Since the edition is configured in this file, this can lead to
errors when it encounters newer syntax, e.g.
error: expected one of `!`, `.`, `::`, `;`, `?`, `where`, `{`, or an operator, found `"rust_minimal"`
--> samples/rust/rust_minimal.rsi:29:49
|
28 | impl ::kernel::ModuleMetadata for RustMinimal {
| - while parsing this item list starting here
29 | const NAME: &'static ::kernel::str::CStr = c"rust_minimal";
| ^^^^^^^^^^^^^^ expected one of 8 possible tokens
30 | }
| - the item list ends here
|
= note: you may be trying to write a c-string literal
= note: c-string literals require Rust 2021 or later
= help: pass `--edition 2024` to `rustc`
= note: for more on editions, read https://doc.rust-lang.org/edition-guide
A workaround is to use `RUSTFMT=n`, which is documented in the `Makefile`
help for cases where macro expanded source may happen to break `rustfmt`
for other reasons, but this is not one of those cases.
One solution would be to pass `--edition`, but we want `rustfmt` to
use the entire configuration, even if currently we essentially use the
default configuration.
Thus explicitly give the path to the config file to `rustfmt` instead.
Reported-by: Alice Ryhl <aliceryhl@google.com>
Fixes: 2f7ab1267d ("Kbuild: add Rust support")
Cc: stable@vger.kernel.org
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260115183832.46595-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The recent changes to get_unaligned() resulted in a new sparse warning:
net/rds/ib_cm.c:96:35: sparse: sparse: incorrect type in argument 1 (different modifiers) @@ expected void * @@ got restricted __be64 const * @@
net/rds/ib_cm.c:96:35: sparse: expected void *
net/rds/ib_cm.c:96:35: sparse: got restricted __be64 const *
The updated get_unaligned_t() uses __unqual_scalar_typeof() to get an
unqualified type. This works correctly for the compilers, but fails for
sparse when the data type is __be64 (or any other __beNN variant).
On sparse runs (C=[12]) __beNN types are annotated with
__attribute__((bitwise)).
That annotation allows sparse to detect incompatible operations on __beNN
variables, but it also prevents sparse from evaluating the _Generic() in
__unqual_scalar_typeof() and map __beNN to a unqualified scalar type, so it
ends up with the default, i.e. the original qualified type of a 'const
__beNN' pointer. That then ends up as the first pointer argument to
builtin_memcpy(), which obviously causes the above sparse warnings.
The sparse git tree supports typeof_unqual() now, which allows to use it
instead of the _Generic() based __unqual_scalar_typeof(). With that sparse
correctly evaluates the unqualified type and keeps the __beNN logic intact.
The downside is that this requires a top of tree sparse build and an old
sparse version will emit a metric ton of incomprehensible error messages
before it dies with a segfault.
Therefore implement a sanity check which validates that the checker is
available and capable of handling typeof_unqual(). Emit a warning if not so
the user can take informed action.
[ tglx: Move the evaluation of USE_TYPEOF_UNQUAL to compiler_types.h so it is
set before use and implement the sanity checker ]
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Acked-by: Ian Rogers <irogers@google.com>
Link: https://patch.msgid.link/87ecnp2zh3.ffs@tglx
Closes: https://lore.kernel.org/oe-kbuild-all/202601150001.sKSN644a-lkp@intel.com/
`syn` makes parsing Rust from proc-macros a lot simpler. `pin-init` has
not used `syn` up until now, because the we did not support it. That
changed in commit 54e3eae855 ("Merge patch series "`syn` support""),
so we can finally utilize the added ergonomics of parsing proc-macro
input with `syn`.
Previously we only had the `proc-macro` library available, whereas the
user-space version also used `proc-macro2` and `quote`. Now both are
available, so remove the workarounds.
Due to these changes, clippy emits warnings about unnecessary
`.to_string()` as `proc-macro2` provides an additional `PartialEq` impl
on `Ident`, so the warnings are fixed.
[ Adjusted wording from upstream version and added build system changes
for the kernel - Benno ]
Co-developed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Tamir Duberstein <tamird@gmail.com>
Tested-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: Benno Lossin <lossin@kernel.org>
