* Re: [PATCH 0/1] rust: module_param: support bool parameters
From: Greg KH @ 2026-04-11 13:20 UTC (permalink / raw)
To: Wenzhao Liao
Cc: mcgrof, petr.pavlu, da.gomez, samitolvanen, ojeda, linux-modules,
rust-for-linux, atomlin, boqun, gary, bjorn3_gh, lossin,
a.hindborg, aliceryhl, tmgross, dakr, linux-kernel
In-Reply-To: <20260411130254.3510128-1-wenzhaoliao@ruc.edu.cn>
On Sat, Apr 11, 2026 at 09:02:53AM -0400, Wenzhao Liao wrote:
> Sorry for the earlier noise and for our unfamiliarity with parts of the
> kernel submission process, which created extra burden for maintainers.
>
> This patch adds boolean module parameter support to the Rust `module!`
> parameter path.
>
> It implements `ModuleParam` for `bool` and wires `PARAM_OPS_BOOL` into
> the Rust module parameter machinery, so Rust-side parsing reuses the
> existing kernel `kstrtobool()` semantics through `kstrtobool_bytes()`
> instead of introducing a separate parser. A boolean parameter is also
> added to `samples/rust/rust_minimal.rs` as a small reference user and
> build-time validation point.
What driver needs this feature? Module options should be very rare
going forward as they are 1990's technology and do not fit the "modern"
kernel model at all.
thanks,
greg k-h
^ permalink raw reply
* [PATCH 1/1] rust: module_param: support bool parameters
From: Wenzhao Liao @ 2026-04-11 13:02 UTC (permalink / raw)
To: mcgrof, petr.pavlu, da.gomez, samitolvanen, ojeda, linux-modules,
rust-for-linux
Cc: atomlin, boqun, gary, bjorn3_gh, lossin, a.hindborg, aliceryhl,
tmgross, dakr, linux-kernel
In-Reply-To: <20260411130254.3510128-1-wenzhaoliao@ruc.edu.cn>
Add support for parsing boolean module parameters in the Rust
module! macro.
Currently, only integer types are supported by the `module_param!`
macros. This patch implements the `ModuleParam` trait for `bool`
by delegating the string parsing to the existing C implementation
via `kstrtobool_bytes()`. It also wires up `PARAM_OPS_BOOL` so that
the Rust parameter system correctly links to the C `param_ops_bool`
structure.
For demonstration and verification, a boolean parameter is added
to `samples/rust/rust_minimal.rs`.
Assisted-by: Codex:GPT-5
Signed-off-by: Wenzhao Liao <wenzhaoliao@ruc.edu.cn>
---
rust/kernel/module_param.rs | 9 ++++++++-
rust/macros/lib.rs | 1 +
rust/macros/module.rs | 1 +
samples/rust/rust_minimal.rs | 8 ++++++++
4 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/rust/kernel/module_param.rs b/rust/kernel/module_param.rs
index 6a8a7a875643..04ce9eda6731 100644
--- a/rust/kernel/module_param.rs
+++ b/rust/kernel/module_param.rs
@@ -5,7 +5,7 @@
//! C header: [`include/linux/moduleparam.h`](srctree/include/linux/moduleparam.h)
use crate::prelude::*;
-use crate::str::BStr;
+use crate::str::{kstrtobool_bytes, BStr};
use bindings;
use kernel::sync::SetOnce;
@@ -106,6 +106,12 @@ fn try_from_param_arg(arg: &BStr) -> Result<Self> {
impl_int_module_param!(isize);
impl_int_module_param!(usize);
+impl ModuleParam for bool {
+ fn try_from_param_arg(arg: &BStr) -> Result<Self> {
+ kstrtobool_bytes(arg)
+ }
+}
+
/// A wrapper for kernel parameters.
///
/// This type is instantiated by the [`module!`] macro when module parameters are
@@ -180,3 +186,4 @@ macro_rules! make_param_ops {
make_param_ops!(PARAM_OPS_U64, u64);
make_param_ops!(PARAM_OPS_ISIZE, isize);
make_param_ops!(PARAM_OPS_USIZE, usize);
+make_param_ops!(PARAM_OPS_BOOL, bool);
diff --git a/rust/macros/lib.rs b/rust/macros/lib.rs
index 0c36194d9971..95bc3f066b49 100644
--- a/rust/macros/lib.rs
+++ b/rust/macros/lib.rs
@@ -52,6 +52,7 @@
/// - [`u64`]
/// - [`isize`]
/// - [`usize`]
+/// - [`bool`]
///
/// C header: [`include/linux/moduleparam.h`](srctree/include/linux/moduleparam.h)
///
diff --git a/rust/macros/module.rs b/rust/macros/module.rs
index e16298e520c7..feafa0c1623c 100644
--- a/rust/macros/module.rs
+++ b/rust/macros/module.rs
@@ -197,6 +197,7 @@ fn param_ops_path(param_type: &str) -> Path {
"u64" => parse_quote!(::kernel::module_param::PARAM_OPS_U64),
"isize" => parse_quote!(::kernel::module_param::PARAM_OPS_ISIZE),
"usize" => parse_quote!(::kernel::module_param::PARAM_OPS_USIZE),
+ "bool" => parse_quote!(::kernel::module_param::PARAM_OPS_BOOL),
t => panic!("Unsupported parameter type {}", t),
}
}
diff --git a/samples/rust/rust_minimal.rs b/samples/rust/rust_minimal.rs
index 8eb9583571d7..fedf5be1f713 100644
--- a/samples/rust/rust_minimal.rs
+++ b/samples/rust/rust_minimal.rs
@@ -15,6 +15,10 @@
default: 1,
description: "This parameter has a default of 1",
},
+ test_bool_parameter: bool {
+ default: false,
+ description: "This boolean parameter defaults to false",
+ },
},
}
@@ -30,6 +34,10 @@ fn init(_module: &'static ThisModule) -> Result<Self> {
"test_parameter: {}\n",
*module_parameters::test_parameter.value()
);
+ pr_info!(
+ "test_bool_parameter: {}\n",
+ *module_parameters::test_bool_parameter.value()
+ );
let mut numbers = KVec::new();
numbers.push(72, GFP_KERNEL)?;
--
2.34.1
^ permalink raw reply related
* [PATCH 0/1] rust: module_param: support bool parameters
From: Wenzhao Liao @ 2026-04-11 13:02 UTC (permalink / raw)
To: mcgrof, petr.pavlu, da.gomez, samitolvanen, ojeda, linux-modules,
rust-for-linux
Cc: atomlin, boqun, gary, bjorn3_gh, lossin, a.hindborg, aliceryhl,
tmgross, dakr, linux-kernel
Sorry for the earlier noise and for our unfamiliarity with parts of the
kernel submission process, which created extra burden for maintainers.
This patch adds boolean module parameter support to the Rust `module!`
parameter path.
It implements `ModuleParam` for `bool` and wires `PARAM_OPS_BOOL` into
the Rust module parameter machinery, so Rust-side parsing reuses the
existing kernel `kstrtobool()` semantics through `kstrtobool_bytes()`
instead of introducing a separate parser. A boolean parameter is also
added to `samples/rust/rust_minimal.rs` as a small reference user and
build-time validation point.
AI assistance: Codex:GPT-5 was used to help draft the `ModuleParam for
bool` implementation, the macro type mapping, and the sample parameter
wiring. I reviewed the resulting code and changelog, tested the change,
and take responsibility for the submission.
Build-tested with:
make -C /home/lwz/rfl-dev/worktrees/rnull-upstream-contribution \
O=/tmp/module-param-bool-build LLVM=-15 defconfig
make -C /home/lwz/rfl-dev/worktrees/rnull-upstream-contribution \
O=/tmp/module-param-bool-build LLVM=-15 rustavailable
scripts/config --file /tmp/module-param-bool-build/.config \
-e RUST -e SAMPLES -e SAMPLES_RUST -m SAMPLE_RUST_MINIMAL
make -C /home/lwz/rfl-dev/worktrees/rnull-upstream-contribution \
O=/tmp/module-param-bool-build LLVM=-15 olddefconfig
make -C /home/lwz/rfl-dev/worktrees/rnull-upstream-contribution \
O=/tmp/module-param-bool-build LLVM=-15 vmlinux
make -C /home/lwz/rfl-dev/worktrees/rnull-upstream-contribution \
O=/tmp/module-param-bool-build LLVM=-15 samples/rust/rust_minimal.ko
Wenzhao Liao (1):
rust: module_param: support bool parameters
rust/kernel/module_param.rs | 9 ++++++++-
rust/macros/lib.rs | 1 +
rust/macros/module.rs | 1 +
samples/rust/rust_minimal.rs | 8 ++++++++
4 files changed, 18 insertions(+), 1 deletion(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH 04/61] ext4: Prefer IS_ERR_OR_NULL over manual NULL check
From: Theodore Ts'o @ 2026-04-10 15:18 UTC (permalink / raw)
To: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Philipp Hahn
Cc: Theodore Ts'o, Andreas Dilger
In-Reply-To: <20260310-b4-is_err_or_null-v1-4-bd63b656022d@avm.de>
On Tue, 10 Mar 2026 12:48:30 +0100, Philipp Hahn wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
Applied, thanks!
[04/61] ext4: Prefer IS_ERR_OR_NULL over manual NULL check
commit: 1d749e110277ce4103f27bd60d6181e52c0cc1e3
Best regards,
--
Theodore Ts'o <tytso@mit.edu>
^ permalink raw reply
* [PATCH] kbuild/btf: Remove broken module relinking exclusion
From: Petr Pavlu @ 2026-04-10 13:13 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko
Cc: Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Luis Chamberlain, Daniel Gomez, Sami Tolvanen, Aaron Tomlin,
Ihor Solodrai, Masahiro Yamada, Sasha Levin, linux-kbuild, bpf,
linux-modules, linux-kernel, Petr Pavlu
Commit 5f9ae91f7c0d ("kbuild: Build kernel module BTFs if BTF is enabled
and pahole supports it") in 2020 introduced CONFIG_DEBUG_INFO_BTF_MODULES
to enable generation of split BTF for kernel modules. This change required
the %.ko Makefile rule to additionally depend on vmlinux, which is used as
a base for deduplication. The regular ld_ko_o command executed by the rule
was then modified to be skipped if only vmlinux changes. This was done by
introducing a new if_changed_except command and updating the original call
to '+$(call if_changed_except,ld_ko_o,vmlinux)'.
Later, commit 214c0eea43b2 ("kbuild: add $(objtree)/ prefix to some
in-kernel build artifacts") in 2024 updated the rule's reference to vmlinux
from 'vmlinux' to '$(objtree)/vmlinux'. This accidentally broke the
previous logic to skip relinking modules if only vmlinux changes. The issue
is that '$(objtree)' is typically '.' and GNU Make normalizes the resulting
prerequisite './vmlinux' to just 'vmlinux', while the exclusion logic
retains the raw './vmlinux'. As a result, if_changed_except doesn't
correctly filter out vmlinux. Consequently, with
CONFIG_DEBUG_INFO_BTF_MODULES=y, modules are relinked even if only vmlinux
changes.
It is possible to fix this Makefile issue. However, having the %.ko rule
update the resulting file in place without starting from the original
inputs is rather fragile. The logic is harder to debug if something breaks
during a subsequent .ko update because the old input is lost due to the
overwrite. Additionally, it requires that the BTF processing is idempotent.
For example, sorting id+flags BTF_SET8 pairs in .BTF_ids by resolve_btfids
currently doesn't have this property.
One option is to split the %.ko target into two rules: the first for
partial linking and the second one for generating the BTF data. However,
this approach runs into an issue with requiring additional intermediate
files, which increases the size of the build directory. On my system, when
using a large distribution config with ~5500 modules, the size of the build
directory with debuginfo enabled is already ~25 GB, with .ko files
occupying ~8 GB. Duplicating these .ko files doesn't seem practical.
Measuring the speed of the %.ko processing shows that the link step is
actually relatively fast. It takes about 20% of the overall rule time,
while the BTF processing accounts for 80%. Moreover, skipping the link part
becomes relevant only during local development. In such cases, developers
typically use configs that enable a limited number of modules, so having
the %.ko rule slightly slower doesn't significantly impact the total
rebuild time. This is supported by the fact that no one has complained
about this optimization being broken for the past two years.
Therefore, remove the logic that prevents module relinking when only
vmlinux changes and simplify Makefile.modfinal.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
My previous attempt to fix this logic can be found at
https://lore.kernel.org/linux-modules/20260402141911.1577711-1-petr.pavlu@suse.com/
---
scripts/Makefile.modfinal | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal
index adcbcde16a07..01a37ec872b9 100644
--- a/scripts/Makefile.modfinal
+++ b/scripts/Makefile.modfinal
@@ -46,17 +46,9 @@ quiet_cmd_btf_ko = BTF [M] $@
$(CONFIG_SHELL) $(srctree)/scripts/gen-btf.sh --btf_base $(objtree)/vmlinux $@; \
fi;
-# Same as newer-prereqs, but allows to exclude specified extra dependencies
-newer_prereqs_except = $(filter-out $(PHONY) $(1),$?)
-
-# Same as if_changed, but allows to exclude specified extra dependencies
-if_changed_except = $(if $(call newer_prereqs_except,$(2))$(cmd-check), \
- $(cmd); \
- printf '%s\n' 'savedcmd_$@ := $(make-cmd)' > $(dot-target).cmd, @:)
-
# Re-generate module BTFs if either module's .ko or vmlinux changed
%.ko: %.o %.mod.o .module-common.o $(objtree)/scripts/module.lds $(and $(CONFIG_DEBUG_INFO_BTF_MODULES),$(KBUILD_BUILTIN),$(objtree)/vmlinux) FORCE
- +$(call if_changed_except,ld_ko_o,$(objtree)/vmlinux)
+ +$(call if_changed,ld_ko_o)
ifdef CONFIG_DEBUG_INFO_BTF_MODULES
+$(if $(newer-prereqs),$(call cmd,btf_ko))
endif
base-commit: 591cd656a1bf5ea94a222af5ef2ee76df029c1d2
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 00/61] treewide: Use IS_ERR_OR_NULL over manual NULL check - refactor
From: Al Viro @ 2026-04-09 18:16 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Julia Lawall, Nicolas Palix, Chris Mason,
David Sterba, Ilya Dryomov, Alex Markuze, Viacheslav Dubeyko,
Theodore Ts'o, Andreas Dilger, Steve French, Paulo Alcantara,
Ronnie Sahlberg, Shyam Prasad N, Tom Talpey, Bharath SM,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Miklos Szeredi,
Konstantin Komarov, Andreas Gruenbacher, Kees Cook, Tony Luck,
Guilherme G. Piccoli, Jan Kara, Phillip Lougher,
Christian Brauner, Jan Kara, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Tejun Heo, David Vernet, Andrea Righi,
Changwoo Min, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Ben Segall, Mel Gorman,
Valentin Schneider, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Sylwester Nawrocki, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Max Filippov,
Paolo Bonzini, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andrew Morton, Alasdair Kergon, Mike Snitzer,
Mikulas Patocka, Benjamin Marzinski, David S. Miller, David Ahern,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Marcel Holtmann, Johan Hedberg, Luiz Augusto von Dentz,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Jamal Hadi Salim, Jiri Pirko,
Marcelo Ricardo Leitner, Xin Long, Trond Myklebust,
Anna Schumaker, Chuck Lever, Jeff Layton, NeilBrown,
Olga Kornievskaia, Dai Ngo, Jon Maloy, Johannes Berg,
Catalin Marinas, Russell King, John Crispin, Thomas Bogendoerfer,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Zhenyu Wang,
Zhi Wang, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Alex Deucher, Christian König, Sandy Huang,
Heiko Stübner, Andy Yan, Igor Russkikh, Andrew Lunn,
Pavan Chebbi, Michael Chan, Potnuri Bharat Teja, Tony Nguyen,
Przemek Kitszel, Taras Chornyi, Maxime Coquelin, Alexandre Torgue,
Iyappan Subramanian, Keyur Chudgar, Quan Nguyen, Heiner Kallweit,
Marc Zyngier, Thomas Gleixner, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Vinod Koul, Linus Walleij, Ulf Hansson,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Martin K. Petersen,
Eduardo Valentin, Keerthy, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Alex Williamson, Mark Greer,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Shuah Khan, Kieran Bingham, Mauro Carvalho Chehab, Joerg Roedel,
Will Deacon, Robin Murphy, Lee Jones, Pavel Machek, Dave Penkler,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Justin Sanders, Jens Axboe, Georgi Djakov, Michael Turquette,
Stephen Boyd, Philipp Zabel, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Pali Rohár, Dmitry Torokhov
In-Reply-To: <20260310-b4-is_err_or_null-v1-0-bd63b656022d@avm.de>
On Tue, Mar 10, 2026 at 12:48:26PM +0100, Philipp Hahn wrote:
> While doing some static code analysis I stumbled over a common pattern,
> where IS_ERR() is combined with a NULL check. For that there is
> IS_ERR_OR_NULL().
... and valid uses of IS_ERR_OR_NULL are rare as hen teeth.
Most of those are "I'm not sure how this function returns an
error, let's use that just in case".
Please, do not introduce more of that crap.
^ permalink raw reply
* Re: [PATCH 1/2] kbuild: rust: allow `clippy::uninlined_format_args`
From: Gary Guo @ 2026-04-09 17:06 UTC (permalink / raw)
To: Tamir Duberstein, Miguel Ojeda
Cc: Miguel Ojeda, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Nathan Chancellor, Nicolas Schier, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, rust-for-linux,
Aaron Tomlin, linux-modules, linux-kernel, linux-kbuild, stable
In-Reply-To: <CAJ-ks9nMA1zqGhHhOk8hmfNgoODQ+D-WforPU6iCciYbPsDD-Q@mail.gmail.com>
On Thu Apr 9, 2026 at 5:18 PM BST, Tamir Duberstein wrote:
> On Fri, Apr 3, 2026 at 9:07 AM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
>>
>> On Fri, Apr 3, 2026 at 12:25 PM Tamir Duberstein <tamird@kernel.org> wrote:
>> >
>> > Seeing this patch a bit late but in clippy 1.85.0 there is
>> > `#[clippy::format_args]` which would permit us to make the lint work
>> > with our custom macros.
>>
>> +1, that may be good to consider, especially with the bump -- added
>> and backlinked in:
>>
>> https://github.com/Rust-for-Linux/linux/issues/349
>>
>> Maybe an issue would be good to create too.
>
> Turns out `#[clippy::format_args]` doesn't work for us due to the
> `fmt!` proc-macro.
>
> It seems the handling of `#[clippy::format_args]` is more
> sophisticated than (at least I) expected: it doesn't blindly check the
> inputs to annotated macros, but rather looks for the place where
> `fmt::Arguments` are created.
>
> In our case something like `pr_info!("{}", i)` ends up expanding to
> `core::format_args!("{}", Adapter(&(i)))`, which does not trigger
> `uninlined_format_args`.
>
> We also cannot fix that just by having `fmt!` assign `Adapter(&(i))`
> to a local variable and then return `fmt::Arguments`, since
> `core::format_args!` borrows its arguments. The local would not live
> long enough.
>
> I filed this upstream as https://github.com/rust-lang/rust-clippy/issues/16833.
The issue is that by the time Clippy lints run, it only have post-expansion
results. The pre-expansion AST is no longer available.
But if you run your lints pre-expansion, the name resolver and query engine is
not yet available (resolution of macro names happen during expansion).
This is generally tricky, the way Clippy works is it tries to reconstruct the
macro invocation from the expanded result.
Best,
Gary
^ permalink raw reply
* Re: [PATCH 1/2] kbuild: rust: allow `clippy::uninlined_format_args`
From: Tamir Duberstein @ 2026-04-09 16:18 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Miguel Ojeda, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Nathan Chancellor, Nicolas Schier, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, rust-for-linux,
Aaron Tomlin, linux-modules, linux-kernel, linux-kbuild, stable
In-Reply-To: <CANiq72mKuQgK_R=xs6270nwYigzCvJiFJ1PcOB+WT3OdXO7E0A@mail.gmail.com>
On Fri, Apr 3, 2026 at 9:07 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Fri, Apr 3, 2026 at 12:25 PM Tamir Duberstein <tamird@kernel.org> wrote:
> >
> > Seeing this patch a bit late but in clippy 1.85.0 there is
> > `#[clippy::format_args]` which would permit us to make the lint work
> > with our custom macros.
>
> +1, that may be good to consider, especially with the bump -- added
> and backlinked in:
>
> https://github.com/Rust-for-Linux/linux/issues/349
>
> Maybe an issue would be good to create too.
Turns out `#[clippy::format_args]` doesn't work for us due to the
`fmt!` proc-macro.
It seems the handling of `#[clippy::format_args]` is more
sophisticated than (at least I) expected: it doesn't blindly check the
inputs to annotated macros, but rather looks for the place where
`fmt::Arguments` are created.
In our case something like `pr_info!("{}", i)` ends up expanding to
`core::format_args!("{}", Adapter(&(i)))`, which does not trigger
`uninlined_format_args`.
We also cannot fix that just by having `fmt!` assign `Adapter(&(i))`
to a local variable and then return `fmt::Arguments`, since
`core::format_args!` borrows its arguments. The local would not live
long enough.
I filed this upstream as https://github.com/rust-lang/rust-clippy/issues/16833.
^ permalink raw reply
* Re: [PATCH v2] module.lds.S: Fix modules on 32-bit parisc architecture
From: Petr Pavlu @ 2026-04-09 12:56 UTC (permalink / raw)
To: Helge Deller
Cc: linux-kernel, linux-parisc, Josh Poimboeuf, Luis Chamberlain,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin, linux-modules
In-Reply-To: <adVukQYvRuuC5F-K@p100>
On 4/7/26 10:52 PM, Helge Deller wrote:
> On the 32-bit parisc architecture, we always used the
> -ffunction-sections compiler option to tell the compiler to put the
> functions into seperate text sections. This is necessary, otherwise
> "big" kernel modules like ext4 or ipv6 fail to load because some
> branches won't be able to reach their stubs.
>
> Commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related
> macros") broke this for parisc because all text sections will get
> unconditionally merged now.
>
> Introduce the ARCH_WANTS_MODULES_TEXT_SECTIONS config option which
> avoids the text section merge for modules, and fix this issue by
> enabling this option by default for 32-bit parisc.
>
> v2: Introduce and use ARCH_WANTS_MODULES_TEXT_SECTIONS option
>
> Fixes: 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros")
> Cc: Josh Poimboeuf <jpoimboe@kernel.org>
> Cc: stable@vger.kernel.org # v6.19+
> Suggested-by: Sami Tolvanen <samitolvanen@google.com>
> Signed-off-by: Helge Deller <deller@gmx.de>
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 102ddbd4298e..78abb8be1e63 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -1128,6 +1128,13 @@ config ARCH_WANTS_MODULES_DATA_IN_VMALLOC
> For architectures like powerpc/32 which have constraints on module
> allocation and need to allocate module data outside of module area.
>
> +config ARCH_WANTS_MODULES_TEXT_SECTIONS
> + bool
> + help
> + For architectures like 32-bit parisc which require that functions in
> + modules have to keep code in own text sections (-ffuntion-sections)
> + and to avoid merging all text into one big text section,
> +
Typos: '-ffuntion-sections' -> '-ffunction-sections' and ',' -> '.'
Otherwise, this looks ok to me. Feel free to add:
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH] tracing: preserve module tracepoint strings
From: Petr Pavlu @ 2026-04-09 12:37 UTC (permalink / raw)
To: Cao Ruichuang
Cc: rostedt, mhiramat, mathieu.desnoyers, mcgrof, da.gomez,
samitolvanen, atomlin, linux-kernel, linux-trace-kernel,
linux-modules
In-Reply-To: <20260406170944.51047-1-create0818@163.com>
On 4/6/26 7:09 PM, Cao Ruichuang wrote:
> tracepoint_string() is documented as exporting constant strings
> through printk_formats, including when it is used from modules.
> That currently does not work.
>
> A small test module that calls
> tracepoint_string("tracepoint_string_test_module_string") loads
> successfully and gets a pointer back, but the string never appears
> in /sys/kernel/tracing/printk_formats. The loader only collects
> __trace_printk_fmt from modules and ignores __tracepoint_str.
>
> Collect module __tracepoint_str entries too, copy them to stable
> tracing-managed storage like module trace_printk formats, and let
> trace_is_tracepoint_string() recognize those copied strings. This
> makes module tracepoint strings visible through printk_formats and
> keeps them accepted by the trace string safety checks.
The documentation for tracepoint_string() in include/linux/tracepoint.h
contains:
* The @str used must be a constant string and persistent as it would not
* make sense to show a string that no longer exists. But it is still fine
* to be used with modules, because when modules are unloaded, if they
* had tracepoints, the ring buffers are cleared too. As long as the string
* does not change during the life of the module, it is fine to use
* tracepoint_string() within a module.
The implemented approach copies all strings referenced by
__tracepoint_str and keeps them for the kernel's lifetime. I wonder if
the code could directly reference the original data and handle its
removal when the module is unloaded, or if the quoted comment should be
updated to reflect the new behavior.
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH] tracing: preserve module tracepoint strings
From: Steven Rostedt @ 2026-04-08 20:32 UTC (permalink / raw)
To: Cao Ruichuang
Cc: mhiramat, mathieu.desnoyers, mcgrof, petr.pavlu, da.gomez,
samitolvanen, atomlin, linux-kernel, linux-trace-kernel,
linux-modules
In-Reply-To: <20260406170944.51047-1-create0818@163.com>
On Tue, 7 Apr 2026 01:09:44 +0800
Cao Ruichuang <create0818@163.com> wrote:
> tracepoint_string() is documented as exporting constant strings
> through printk_formats, including when it is used from modules.
> That currently does not work.
>
> A small test module that calls
> tracepoint_string("tracepoint_string_test_module_string") loads
> successfully and gets a pointer back, but the string never appears
> in /sys/kernel/tracing/printk_formats. The loader only collects
> __trace_printk_fmt from modules and ignores __tracepoint_str.
>
> Collect module __tracepoint_str entries too, copy them to stable
> tracing-managed storage like module trace_printk formats, and let
> trace_is_tracepoint_string() recognize those copied strings. This
> makes module tracepoint strings visible through printk_formats and
> keeps them accepted by the trace string safety checks.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217196
> Signed-off-by: Cao Ruichuang <create0818@163.com>
> ---
As this is not a trivial change, and affects module code, I'm going to hold
off until after v7.1-rc1 to apply it.
-- Steve
^ permalink raw reply
* Re: [PATCH v2 1/2] module/kallsyms: fix nextval for data symbol lookup
From: Petr Pavlu @ 2026-04-08 15:24 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-modules, Sami Tolvanen, Luis Chamberlain, linux-kernel,
linux-trace-kernel, live-patching, Daniel Gomez, Aaron Tomlin,
Steven Rostedt, Masami Hiramatsu, Jordan Rome, Viktor Malik
In-Reply-To: <20260327110005.16499-1-stf_xl@wp.pl>
On 3/27/26 12:00 PM, Stanislaw Gruszka wrote:
> The symbol lookup code assumes the queried address resides in either
> MOD_TEXT or MOD_INIT_TEXT. This breaks for addresses in other module
> memory regions (e.g. rodata or data), resulting in incorrect upper
> bounds and wrong symbol size.
>
> Select the module memory region the address belongs to instead of
> hardcoding text sections. Also initialize the lower bound to the start
> of that region, as searching from address 0 is unnecessary.
>
> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Looks ok to me. Feel free to add:
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
As a side note, I wonder if manually determining symbol sizes this way
is the best approach for modules, instead of simply returning the
st_size of the symbol. The logic comes from the original implementation
in "[PATCH] kallsyms for new modules" [1]. Unfortunately, the
description doesn't explain this aspect but considering that the patch
rewrote both the main and module kallsyms code, I expect it was done
this way for consistency between vmlinux and modules.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux-fullhistory.git/commit/?id=d069cf94ca296b7fb4c7e362e8f27e2c8aca70f1
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH] kbuild/btf: Avoid relinking modules when only vmlinux changes
From: Petr Pavlu @ 2026-04-08 13:43 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko
Cc: Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Luis Chamberlain, Daniel Gomez, Sami Tolvanen, Aaron Tomlin,
Ihor Solodrai, Masahiro Yamada, linux-kbuild, bpf, linux-modules,
linux-kernel
In-Reply-To: <dc3db54f-f95d-46aa-ad84-6258abd13fab@suse.com>
On 4/7/26 1:30 PM, Petr Pavlu wrote:
> On 4/2/26 4:17 PM, Petr Pavlu wrote:
>> Commit 5f9ae91f7c0d ("kbuild: Build kernel module BTFs if BTF is enabled
>> and pahole supports it") in 2020 introduced CONFIG_DEBUG_INFO_BTF_MODULES
>> to enable generation of split BTF for kernel modules. This change required
>> the %.ko Makefile rule to additionally depend on vmlinux, which is used as
>> a base for deduplication. The regular ld_ko_o command executed by the rule
>> was then modified to be skipped if only vmlinux changes. This was done by
>> introducing a new if_changed_except command and updating the original call
>> to '+$(call if_changed_except,ld_ko_o,vmlinux)'.
>>
>> Later, commit 214c0eea43b2 ("kbuild: add $(objtree)/ prefix to some
>> in-kernel build artifacts") in 2024 updated the rule's reference to vmlinux
>> from 'vmlinux' to '$(objtree)/vmlinux'. This accidentally broke the
>> previous logic to skip relinking modules if only vmlinux changes. The issue
>> is that '$(objtree)' is typically '.' and GNU Make normalizes the resulting
>> prerequisite './vmlinux' to just 'vmlinux', while the exclusion logic
>> retains the raw './vmlinux'. As a result, if_changed_except doesn't
>> correctly filter out vmlinux. Consequently, with
>> CONFIG_DEBUG_INFO_BTF_MODULES=y, modules are relinked even if only vmlinux
>> changes.
>>
>> Additionally, commit 522397d05e7d ("resolve_btfids: Change in-place update
>> with raw binary output") in 2025 reworked the method for patching BTF data
>> into the resulting modules by using 'objcopy --add-section'. This command
>> fails if a section already exists.
>>
>> Fix the unnecessary relinking issue by also excluding the normalized form
>> 'vmlinux' when invoking ld_ko_o. Adjust embed_btf_data() to first use the
>> --remove-section option to remove the patched BTF section if it is already
>> present.
>
> I noticed that sorting id+flags in BTF_SET8 by resolve_btfids doesn't
> seem to be idempotent, so this requires additional work.
It is possible to make sorting id+flags in BTF_SET8 by resolve_btfids
idempotent. One approach would be to also update the offsets (st_value)
of the __BTF_ID__* symbols so that they reflect the result after
sorting.
However, I don't think this is worth doing. Since this logic would be
relevant in specific cases when vmlinux changes and only the BTF data
needs to be regenerated, it would have limited usage and testing.
Importantly, always relinking the modules adds only about 6% to the
rebuild time of the modules target on my system when vmlinux is touched.
The work required for BTF and Makefile processing dominates this target.
When developing the kernel locally, it's common to use a custom config
with a limited amount of modules. In such a case, avoiding the relinking
of modules saves very little.
I plan to instead send a patch to replace the current condition that
invokes ld_ko_o from if_changed_except to if_changed, and remove the
if_changed_except logic.
-- Petr
^ permalink raw reply
* [PATCH v2] module.lds.S: Fix modules on 32-bit parisc architecture
From: Helge Deller @ 2026-04-07 20:52 UTC (permalink / raw)
To: linux-kernel, linux-parisc, Josh Poimboeuf, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, Aaron Tomlin,
linux-modules
On the 32-bit parisc architecture, we always used the
-ffunction-sections compiler option to tell the compiler to put the
functions into seperate text sections. This is necessary, otherwise
"big" kernel modules like ext4 or ipv6 fail to load because some
branches won't be able to reach their stubs.
Commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related
macros") broke this for parisc because all text sections will get
unconditionally merged now.
Introduce the ARCH_WANTS_MODULES_TEXT_SECTIONS config option which
avoids the text section merge for modules, and fix this issue by
enabling this option by default for 32-bit parisc.
v2: Introduce and use ARCH_WANTS_MODULES_TEXT_SECTIONS option
Fixes: 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros")
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: stable@vger.kernel.org # v6.19+
Suggested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Helge Deller <deller@gmx.de>
diff --git a/arch/Kconfig b/arch/Kconfig
index 102ddbd4298e..78abb8be1e63 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1128,6 +1128,13 @@ config ARCH_WANTS_MODULES_DATA_IN_VMALLOC
For architectures like powerpc/32 which have constraints on module
allocation and need to allocate module data outside of module area.
+config ARCH_WANTS_MODULES_TEXT_SECTIONS
+ bool
+ help
+ For architectures like 32-bit parisc which require that functions in
+ modules have to keep code in own text sections (-ffuntion-sections)
+ and to avoid merging all text into one big text section,
+
config ARCH_WANTS_EXECMEM_LATE
bool
help
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 62d5a89d5c7b..5a8cd50e8d70 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -8,6 +8,7 @@ config PARISC
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_SYSCALL_TRACEPOINTS
select ARCH_WANT_FRAME_POINTERS
+ select ARCH_WANTS_MODULES_TEXT_SECTIONS if !64BIT
select ARCH_HAS_CPU_CACHE_ALIASING
select ARCH_HAS_DMA_ALLOC if PA11
select ARCH_HAS_DMA_OPS
diff --git a/scripts/module.lds.S b/scripts/module.lds.S
index 054ef99e8288..7c017b997fd7 100644
--- a/scripts/module.lds.S
+++ b/scripts/module.lds.S
@@ -41,9 +41,11 @@ SECTIONS {
__kcfi_traps : { KEEP(*(.kcfi_traps)) }
#endif
+#ifndef CONFIG_ARCH_WANTS_MODULES_TEXT_SECTIONS
.text : {
*(.text .text.[0-9a-zA-Z_]*)
}
+#endif
.bss : {
*(.bss .bss.[0-9a-zA-Z_]*)
^ permalink raw reply related
* Re: [PATCH] module.lds.S: Fix modules on 32-bit parisc architecture
From: Helge Deller @ 2026-04-07 20:03 UTC (permalink / raw)
To: Sami Tolvanen, Helge Deller
Cc: linux-kernel, linux-parisc, Josh Poimboeuf, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Aaron Tomlin, linux-modules
In-Reply-To: <CABCJKucmXyTUxE6fApftqLOTwOgOLu166Gd_K-JeBqAZenou1A@mail.gmail.com>
On 4/7/26 18:26, Sami Tolvanen wrote:
> Hi Helge,
>
> On Sat, Apr 4, 2026 at 1:04 PM Helge Deller <deller@kernel.org> wrote:
>>
>> On the 32-bit parisc architecture, we always used the
>> -ffunction-sections compiler option to tell the compiler to put the
>> functions into seperate text sections. This is necessary, otherwise
>> "big" kernel modules like ext4 or ipv6 fail to load because some
>> branches won't be able to reach their stubs.
>>
>> Commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related
>> macros") broke this for parisc because all text sections will get
>> unconditionally merged now.
>>
>> Fix the issue by avoiding the text section merge for 32-bit parisc while still
>> allowing it for all other architectures.
>>
>> Fixes: 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros")
>> Cc: Josh Poimboeuf <jpoimboe@kernel.org>
>> Cc: stable@vger.kernel.org # v6.19+
>> Signed-off-by: Helge Deller <deller@gmx.de>
>>
>> diff --git a/scripts/module.lds.S b/scripts/module.lds.S
>> index 054ef99e8288..41e13e9cbb9d 100644
>> --- a/scripts/module.lds.S
>> +++ b/scripts/module.lds.S
>> @@ -41,9 +41,11 @@ SECTIONS {
>> __kcfi_traps : { KEEP(*(.kcfi_traps)) }
>> #endif
>>
>> +#if !defined(CONFIG_PARISC) || defined(CONFIG_64BIT)
>
> Instead of adding parisc-specific policies to the main module linker
> script, could we add a separate config flag for this and have parisc
> select that in its own Kconfig for !64BIT? Perhaps something like
> ARCH_WANTS_MODULE_TEXT_SECTIONS?
Yes, good idea!
I will send a v2 patch.
Helge
^ permalink raw reply
* Re: [PATCH] module.lds.S: Fix modules on 32-bit parisc architecture
From: Sami Tolvanen @ 2026-04-07 16:26 UTC (permalink / raw)
To: Helge Deller
Cc: linux-kernel, linux-parisc, Josh Poimboeuf, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Aaron Tomlin, linux-modules
In-Reply-To: <adFuw1E4iVyiXLf_@p100>
Hi Helge,
On Sat, Apr 4, 2026 at 1:04 PM Helge Deller <deller@kernel.org> wrote:
>
> On the 32-bit parisc architecture, we always used the
> -ffunction-sections compiler option to tell the compiler to put the
> functions into seperate text sections. This is necessary, otherwise
> "big" kernel modules like ext4 or ipv6 fail to load because some
> branches won't be able to reach their stubs.
>
> Commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related
> macros") broke this for parisc because all text sections will get
> unconditionally merged now.
>
> Fix the issue by avoiding the text section merge for 32-bit parisc while still
> allowing it for all other architectures.
>
> Fixes: 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros")
> Cc: Josh Poimboeuf <jpoimboe@kernel.org>
> Cc: stable@vger.kernel.org # v6.19+
> Signed-off-by: Helge Deller <deller@gmx.de>
>
> diff --git a/scripts/module.lds.S b/scripts/module.lds.S
> index 054ef99e8288..41e13e9cbb9d 100644
> --- a/scripts/module.lds.S
> +++ b/scripts/module.lds.S
> @@ -41,9 +41,11 @@ SECTIONS {
> __kcfi_traps : { KEEP(*(.kcfi_traps)) }
> #endif
>
> +#if !defined(CONFIG_PARISC) || defined(CONFIG_64BIT)
Instead of adding parisc-specific policies to the main module linker
script, could we add a separate config flag for this and have parisc
select that in its own Kconfig for !64BIT? Perhaps something like
ARCH_WANTS_MODULE_TEXT_SECTIONS?
Sami
^ permalink raw reply
* Re: [PATCH] kbuild/btf: Avoid relinking modules when only vmlinux changes
From: Petr Pavlu @ 2026-04-07 11:30 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko
Cc: Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Luis Chamberlain, Daniel Gomez, Sami Tolvanen, Aaron Tomlin,
Ihor Solodrai, Masahiro Yamada, linux-kbuild, bpf, linux-modules,
linux-kernel
In-Reply-To: <20260402141911.1577711-1-petr.pavlu@suse.com>
On 4/2/26 4:17 PM, Petr Pavlu wrote:
> Commit 5f9ae91f7c0d ("kbuild: Build kernel module BTFs if BTF is enabled
> and pahole supports it") in 2020 introduced CONFIG_DEBUG_INFO_BTF_MODULES
> to enable generation of split BTF for kernel modules. This change required
> the %.ko Makefile rule to additionally depend on vmlinux, which is used as
> a base for deduplication. The regular ld_ko_o command executed by the rule
> was then modified to be skipped if only vmlinux changes. This was done by
> introducing a new if_changed_except command and updating the original call
> to '+$(call if_changed_except,ld_ko_o,vmlinux)'.
>
> Later, commit 214c0eea43b2 ("kbuild: add $(objtree)/ prefix to some
> in-kernel build artifacts") in 2024 updated the rule's reference to vmlinux
> from 'vmlinux' to '$(objtree)/vmlinux'. This accidentally broke the
> previous logic to skip relinking modules if only vmlinux changes. The issue
> is that '$(objtree)' is typically '.' and GNU Make normalizes the resulting
> prerequisite './vmlinux' to just 'vmlinux', while the exclusion logic
> retains the raw './vmlinux'. As a result, if_changed_except doesn't
> correctly filter out vmlinux. Consequently, with
> CONFIG_DEBUG_INFO_BTF_MODULES=y, modules are relinked even if only vmlinux
> changes.
>
> Additionally, commit 522397d05e7d ("resolve_btfids: Change in-place update
> with raw binary output") in 2025 reworked the method for patching BTF data
> into the resulting modules by using 'objcopy --add-section'. This command
> fails if a section already exists.
>
> Fix the unnecessary relinking issue by also excluding the normalized form
> 'vmlinux' when invoking ld_ko_o. Adjust embed_btf_data() to first use the
> --remove-section option to remove the patched BTF section if it is already
> present.
I noticed that sorting id+flags in BTF_SET8 by resolve_btfids doesn't
seem to be idempotent, so this requires additional work.
-- Petr
^ permalink raw reply
* [PATCH] tracing: preserve module tracepoint strings
From: Cao Ruichuang @ 2026-04-06 17:09 UTC (permalink / raw)
To: rostedt
Cc: mhiramat, mathieu.desnoyers, mcgrof, petr.pavlu, da.gomez,
samitolvanen, atomlin, linux-kernel, linux-trace-kernel,
linux-modules
tracepoint_string() is documented as exporting constant strings
through printk_formats, including when it is used from modules.
That currently does not work.
A small test module that calls
tracepoint_string("tracepoint_string_test_module_string") loads
successfully and gets a pointer back, but the string never appears
in /sys/kernel/tracing/printk_formats. The loader only collects
__trace_printk_fmt from modules and ignores __tracepoint_str.
Collect module __tracepoint_str entries too, copy them to stable
tracing-managed storage like module trace_printk formats, and let
trace_is_tracepoint_string() recognize those copied strings. This
makes module tracepoint strings visible through printk_formats and
keeps them accepted by the trace string safety checks.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217196
Signed-off-by: Cao Ruichuang <create0818@163.com>
---
include/linux/module.h | 2 ++
kernel/module/main.c | 4 +++
kernel/trace/trace_printk.c | 63 ++++++++++++++++++++++++++++---------
3 files changed, 54 insertions(+), 15 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 14f391b18..e475466a7 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -515,6 +515,8 @@ struct module {
#ifdef CONFIG_TRACING
unsigned int num_trace_bprintk_fmt;
const char **trace_bprintk_fmt_start;
+ unsigned int num_tracepoint_strings;
+ const char **tracepoint_strings_start;
#endif
#ifdef CONFIG_EVENT_TRACING
struct trace_event_call **trace_events;
diff --git a/kernel/module/main.c b/kernel/module/main.c
index c3ce106c7..d7d890138 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2672,6 +2672,10 @@ static int find_module_sections(struct module *mod, struct load_info *info)
mod->trace_bprintk_fmt_start = section_objs(info, "__trace_printk_fmt",
sizeof(*mod->trace_bprintk_fmt_start),
&mod->num_trace_bprintk_fmt);
+ mod->tracepoint_strings_start =
+ section_objs(info, "__tracepoint_str",
+ sizeof(*mod->tracepoint_strings_start),
+ &mod->num_tracepoint_strings);
#endif
#ifdef CONFIG_DYNAMIC_FTRACE
/* sechdrs[0].sh_size is always zero */
diff --git a/kernel/trace/trace_printk.c b/kernel/trace/trace_printk.c
index 5ea5e0d76..9f67ce42e 100644
--- a/kernel/trace/trace_printk.c
+++ b/kernel/trace/trace_printk.c
@@ -22,8 +22,9 @@
#ifdef CONFIG_MODULES
/*
- * modules trace_printk()'s formats are autosaved in struct trace_bprintk_fmt
- * which are queued on trace_bprintk_fmt_list.
+ * modules trace_printk() formats and tracepoint_string() strings are
+ * autosaved in struct trace_bprintk_fmt, which are queued on
+ * trace_bprintk_fmt_list.
*/
static LIST_HEAD(trace_bprintk_fmt_list);
@@ -33,8 +34,12 @@ static DEFINE_MUTEX(btrace_mutex);
struct trace_bprintk_fmt {
struct list_head list;
const char *fmt;
+ unsigned int type;
};
+#define TRACE_BPRINTK_TYPE BIT(0)
+#define TRACE_TRACEPOINT_TYPE BIT(1)
+
static inline struct trace_bprintk_fmt *lookup_format(const char *fmt)
{
struct trace_bprintk_fmt *pos;
@@ -49,22 +54,24 @@ static inline struct trace_bprintk_fmt *lookup_format(const char *fmt)
return NULL;
}
-static
-void hold_module_trace_bprintk_format(const char **start, const char **end)
+static void hold_module_trace_format(const char **start, const char **end,
+ unsigned int type)
{
const char **iter;
char *fmt;
/* allocate the trace_printk per cpu buffers */
- if (start != end)
+ if ((type & TRACE_BPRINTK_TYPE) && start != end)
trace_printk_init_buffers();
mutex_lock(&btrace_mutex);
for (iter = start; iter < end; iter++) {
struct trace_bprintk_fmt *tb_fmt = lookup_format(*iter);
if (tb_fmt) {
- if (!IS_ERR(tb_fmt))
+ if (!IS_ERR(tb_fmt)) {
+ tb_fmt->type |= type;
*iter = tb_fmt->fmt;
+ }
continue;
}
@@ -76,6 +83,7 @@ void hold_module_trace_bprintk_format(const char **start, const char **end)
list_add_tail(&tb_fmt->list, &trace_bprintk_fmt_list);
strcpy(fmt, *iter);
tb_fmt->fmt = fmt;
+ tb_fmt->type = type;
} else
kfree(tb_fmt);
}
@@ -85,17 +93,28 @@ void hold_module_trace_bprintk_format(const char **start, const char **end)
mutex_unlock(&btrace_mutex);
}
-static int module_trace_bprintk_format_notify(struct notifier_block *self,
- unsigned long val, void *data)
+static int module_trace_format_notify(struct notifier_block *self,
+ unsigned long val, void *data)
{
struct module *mod = data;
+
+ if (val != MODULE_STATE_COMING)
+ return NOTIFY_OK;
+
if (mod->num_trace_bprintk_fmt) {
const char **start = mod->trace_bprintk_fmt_start;
const char **end = start + mod->num_trace_bprintk_fmt;
- if (val == MODULE_STATE_COMING)
- hold_module_trace_bprintk_format(start, end);
+ hold_module_trace_format(start, end, TRACE_BPRINTK_TYPE);
+ }
+
+ if (mod->num_tracepoint_strings) {
+ const char **start = mod->tracepoint_strings_start;
+ const char **end = start + mod->num_tracepoint_strings;
+
+ hold_module_trace_format(start, end, TRACE_TRACEPOINT_TYPE);
}
+
return NOTIFY_OK;
}
@@ -171,8 +190,8 @@ static void format_mod_stop(void)
#else /* !CONFIG_MODULES */
__init static int
-module_trace_bprintk_format_notify(struct notifier_block *self,
- unsigned long val, void *data)
+module_trace_format_notify(struct notifier_block *self,
+ unsigned long val, void *data)
{
return NOTIFY_OK;
}
@@ -193,8 +212,8 @@ void trace_printk_control(bool enabled)
}
__initdata_or_module static
-struct notifier_block module_trace_bprintk_format_nb = {
- .notifier_call = module_trace_bprintk_format_notify,
+struct notifier_block module_trace_format_nb = {
+ .notifier_call = module_trace_format_notify,
};
int __trace_bprintk(unsigned long ip, const char *fmt, ...)
@@ -254,11 +273,25 @@ EXPORT_SYMBOL_GPL(__ftrace_vprintk);
bool trace_is_tracepoint_string(const char *str)
{
const char **ptr = __start___tracepoint_str;
+#ifdef CONFIG_MODULES
+ struct trace_bprintk_fmt *tb_fmt;
+#endif
for (ptr = __start___tracepoint_str; ptr < __stop___tracepoint_str; ptr++) {
if (str == *ptr)
return true;
}
+
+#ifdef CONFIG_MODULES
+ mutex_lock(&btrace_mutex);
+ list_for_each_entry(tb_fmt, &trace_bprintk_fmt_list, list) {
+ if ((tb_fmt->type & TRACE_TRACEPOINT_TYPE) && str == tb_fmt->fmt) {
+ mutex_unlock(&btrace_mutex);
+ return true;
+ }
+ }
+ mutex_unlock(&btrace_mutex);
+#endif
return false;
}
@@ -824,7 +857,7 @@ fs_initcall(init_trace_printk_function_export);
static __init int init_trace_printk(void)
{
- return register_module_notifier(&module_trace_bprintk_format_nb);
+ return register_module_notifier(&module_trace_format_nb);
}
early_initcall(init_trace_printk);
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* [PATCH] module.lds.S: Fix modules on 32-bit parisc architecture
From: Helge Deller @ 2026-04-04 20:04 UTC (permalink / raw)
To: linux-kernel, linux-parisc, Josh Poimboeuf, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, Aaron Tomlin,
linux-modules
On the 32-bit parisc architecture, we always used the
-ffunction-sections compiler option to tell the compiler to put the
functions into seperate text sections. This is necessary, otherwise
"big" kernel modules like ext4 or ipv6 fail to load because some
branches won't be able to reach their stubs.
Commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related
macros") broke this for parisc because all text sections will get
unconditionally merged now.
Fix the issue by avoiding the text section merge for 32-bit parisc while still
allowing it for all other architectures.
Fixes: 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros")
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: stable@vger.kernel.org # v6.19+
Signed-off-by: Helge Deller <deller@gmx.de>
diff --git a/scripts/module.lds.S b/scripts/module.lds.S
index 054ef99e8288..41e13e9cbb9d 100644
--- a/scripts/module.lds.S
+++ b/scripts/module.lds.S
@@ -41,9 +41,11 @@ SECTIONS {
__kcfi_traps : { KEEP(*(.kcfi_traps)) }
#endif
+#if !defined(CONFIG_PARISC) || defined(CONFIG_64BIT)
.text : {
*(.text .text.[0-9a-zA-Z_]*)
}
+#endif
.bss : {
*(.bss .bss.[0-9a-zA-Z_]*)
^ permalink raw reply related
* Re: [PATCH v2 0/2] module: Tweak return and warning
From: Sami Tolvanen @ 2026-04-04 0:37 UTC (permalink / raw)
To: Luis Chamberlain, Daniel Gomez, Lucas De Marchi
Cc: Sami Tolvanen, Greg Kroah-Hartman, Aaron Tomlin, Petr Pavlu,
Daniel Gomez, Phil Sutter, linux-modules, linux-kernel,
Christophe Leroy
In-Reply-To: <-v2-0-a3542e15111c@kernel.org>
On Mon, 30 Mar 2026 08:13:50 -0500, Lucas De Marchi wrote:
> Do not let userspace tools and end users confused on the return code and
> log messages.
>
> To: Luis Chamberlain <mcgrof@kernel.org>
> To: Daniel Gomez <da.gomez@kernel.org>
> To: Sami Tolvanen <samitolvanen@google.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Aaron Tomlin <atomlin@atomlin.com>
> Cc: Petr Pavlu <petr.pavlu@suse.com>
> Cc: Daniel Gomez <da.gomez@samsung.com>
> Cc: Phil Sutter <phil@nwl.cc>
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: linux-modules@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> [...]
Applied to modules-next, thanks!
[1/2] module: Override -EEXIST module return
commit: 743f8cae549affe8eafb021b8c0e78a9f3bc23fa
[2/2] module: Simplify warning on positive returns from module_init()
commit: 663385f9155f27892a97a5824006f806a32eb8dc
Best regards,
Sami
^ permalink raw reply
* Re: [PATCH 2/2] rust: macros: simplify `format!` arguments
From: Miguel Ojeda @ 2026-04-03 21:23 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Miguel Ojeda, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Nathan Chancellor, Nicolas Schier, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, rust-for-linux, Aaron Tomlin,
linux-modules, linux-kernel, linux-kbuild
In-Reply-To: <CABCJKucPKB-ntYi=EzPqyypy0kEHwnZvEvCEyjdQUWqfeAnGig@mail.gmail.com>
On Fri, Apr 3, 2026 at 5:53 PM Sami Tolvanen <samitolvanen@google.com> wrote:
>
> Sounds good to me, thanks.
>
> Acked-by: Sami Tolvanen <samitolvanen@google.com>
Great, I have added the tag now -- thanks!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 2/2] rust: macros: simplify `format!` arguments
From: Sami Tolvanen @ 2026-04-03 15:52 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Miguel Ojeda, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Nathan Chancellor, Nicolas Schier, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, rust-for-linux, Aaron Tomlin,
linux-modules, linux-kernel, linux-kbuild
In-Reply-To: <CANiq72kNqmGpFurRy2X+a=9fHV_hxpfWBJ-+dEL_qj2daLM8ww@mail.gmail.com>
Hi Miguel,
On Thu, Apr 2, 2026 at 9:53 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Tue, Mar 31, 2026 at 10:59 PM Miguel Ojeda <ojeda@kernel.org> wrote:
> >
> > Clippy in Rust 1.88.0 (only) reported [1] up to the previous commit:
> >
> > warning: variables can be used directly in the `format!` string
> > --> rust/macros/module.rs:112:23
> > |
> > 112 | let content = format!("{param}:{content}", param = param, content = content);
> > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > |
> > = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
> > = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all`
> > = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]`
> > help: change this to
> > |
> > 112 - let content = format!("{param}:{content}", param = param, content = content);
> > 112 + let content = format!("{param}:{content}");
> >
> > The reason it only triggers in that version is that the lint was moved
> > from `pedantic` to `style` in Rust 1.88.0 and then back to `pedantic`
> > in Rust 1.89.0 [2][3].
> >
> > In this case, the suggestion is fair and a pure simplification, thus
> > just apply it.
> >
> > In addition, do the same for another place in the file that Clippy does
> > not report because it is multi-line.
> >
> > Link: https://lore.kernel.org/rust-for-linux/CANiq72=drAtf3y_DZ-2o4jb6Az9J3Yj4QYwWnbRui4sm4AJD3Q@mail.gmail.com/ [1]
> > Link: https://github.com/rust-lang/rust-clippy/pull/15287 [2]
> > Link: https://github.com/rust-lang/rust-clippy/issues/15151 [3]
> > Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
>
> I will pick this one up together with the other one, but if someone
> prefers that I don't, please shout (e.g. if modules wants to pick it
> themselves).
Sounds good to me, thanks.
> An Acked-by is also appreciated, thanks!
Acked-by: Sami Tolvanen <samitolvanen@google.com>
Sami
^ permalink raw reply
* Re: [PATCH 1/2] kbuild: rust: allow `clippy::uninlined_format_args`
From: Miguel Ojeda @ 2026-04-03 13:07 UTC (permalink / raw)
To: Tamir Duberstein
Cc: Miguel Ojeda, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Nathan Chancellor, Nicolas Schier, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, rust-for-linux,
Aaron Tomlin, linux-modules, linux-kernel, linux-kbuild, stable
In-Reply-To: <CAJ-ks9nqv30SOiCia8LE6XbKEURNCa9qwwcszsQ0a8FRxR0Msg@mail.gmail.com>
On Fri, Apr 3, 2026 at 12:25 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> Seeing this patch a bit late but in clippy 1.85.0 there is
> `#[clippy::format_args]` which would permit us to make the lint work
> with our custom macros.
+1, that may be good to consider, especially with the bump -- added
and backlinked in:
https://github.com/Rust-for-Linux/linux/issues/349
Maybe an issue would be good to create too.
It is good to see Clippy adding more attributes, because I requested a
similar one for other lints involving macros in that list, e.g.
https://github.com/rust-lang/rust-clippy/issues/11303
So hopefully we will eventually get those too.
Thanks!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 1/2] kbuild: rust: allow `clippy::uninlined_format_args`
From: Tamir Duberstein @ 2026-04-03 10:24 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Nathan Chancellor, Nicolas Schier, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, rust-for-linux, Aaron Tomlin,
linux-modules, linux-kernel, linux-kbuild, stable
In-Reply-To: <20260331205849.498295-1-ojeda@kernel.org>
On Tue, Mar 31, 2026 at 4:59 PM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> Clippy in Rust 1.88.0 (only) reports [1]:
>
> warning: variables can be used directly in the `format!` string
> --> rust/macros/module.rs:112:23
> |
> 112 | let content = format!("{param}:{content}", param = param, content = content);
> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |
> = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
> = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all`
> = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]`
> help: change this to
> |
> 112 - let content = format!("{param}:{content}", param = param, content = content);
> 112 + let content = format!("{param}:{content}");
>
> warning: variables can be used directly in the `format!` string
> --> rust/macros/module.rs:198:14
> |
> 198 | t => panic!("Unsupported parameter type {}", t),
> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |
> = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
> = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all`
> = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]`
> help: change this to
> |
> 198 - t => panic!("Unsupported parameter type {}", t),
> 198 + t => panic!("Unsupported parameter type {t}"),
> |
>
> The reason it only triggers in that version is that the lint was moved
> from `pedantic` to `style` in Rust 1.88.0 and then back to `pedantic`
> in Rust 1.89.0 [2][3].
>
> In the first case, the suggestion is fair and a pure simplification, thus
> we will clean it up separately.
>
> To keep the behavior the same across all versions, and since the lint
> does not work for all macros (e.g. custom ones like `pr_info!`), disable
> it globally.
Seeing this patch a bit late but in clippy 1.85.0 there is
`#[clippy::format_args]` which would permit us to make the lint work
with our custom macros.
https://doc.rust-lang.org/nightly/clippy/attribs.html#clippyformat_args
^ permalink raw reply
* Re: [PATCH 1/2] kbuild: rust: allow `clippy::uninlined_format_args`
From: Miguel Ojeda @ 2026-04-03 10:06 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Nathan Chancellor, Nicolas Schier, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, rust-for-linux, Aaron Tomlin,
linux-modules, linux-kernel, linux-kbuild, stable
In-Reply-To: <20260331205849.498295-1-ojeda@kernel.org>
On Tue, Mar 31, 2026 at 10:59 PM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> Clippy in Rust 1.88.0 (only) reports [1]:
>
> warning: variables can be used directly in the `format!` string
> --> rust/macros/module.rs:112:23
> |
> 112 | let content = format!("{param}:{content}", param = param, content = content);
> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |
> = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
> = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all`
> = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]`
> help: change this to
> |
> 112 - let content = format!("{param}:{content}", param = param, content = content);
> 112 + let content = format!("{param}:{content}");
>
> warning: variables can be used directly in the `format!` string
> --> rust/macros/module.rs:198:14
> |
> 198 | t => panic!("Unsupported parameter type {}", t),
> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |
> = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
> = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all`
> = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]`
> help: change this to
> |
> 198 - t => panic!("Unsupported parameter type {}", t),
> 198 + t => panic!("Unsupported parameter type {t}"),
> |
>
> The reason it only triggers in that version is that the lint was moved
> from `pedantic` to `style` in Rust 1.88.0 and then back to `pedantic`
> in Rust 1.89.0 [2][3].
>
> In the first case, the suggestion is fair and a pure simplification, thus
> we will clean it up separately.
>
> To keep the behavior the same across all versions, and since the lint
> does not work for all macros (e.g. custom ones like `pr_info!`), disable
> it globally.
>
> Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
> Link: https://lore.kernel.org/rust-for-linux/CANiq72=drAtf3y_DZ-2o4jb6Az9J3Yj4QYwWnbRui4sm4AJD3Q@mail.gmail.com/ [1]
> Link: https://github.com/rust-lang/rust-clippy/pull/15287 [2]
> Link: https://github.com/rust-lang/rust-clippy/issues/15151 [3]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Applied series to `rust-next` -- thanks everyone!
(If wanted by modules, I can drop the top commit.)
Cheers,
Miguel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox