* Re: [PATCH] rust: module_param: add missing newline to pr_warn
From: Miguel Ojeda @ 2026-05-29 5:15 UTC (permalink / raw)
To: Kenny Glowner
Cc: Sami Tolvanen, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Miguel Ojeda, linux-modules, rust-for-linux, linux-kernel
In-Reply-To: <CANN+23v9vkzq_2o01z2VmkDnLaBTP8_Op5vvu=Ozg21T3o6m3w@mail.gmail.com>
On Fri, May 29, 2026 at 2:55 AM Kenny Glowner
<sisyphuscode0311@gmail.com> wrote:
>
> I hope I submitted everything correctly? I am trying to get used to it so I can provide better assistance on more mainstream issues. That's why I started with the most minor issue I could find. I appreciate all of the feedback.
Yes, it looks fine, thanks! :)
However, in general, please try to reply to the feedback, e.g. I asked
a question about the commit message.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] rust: module_param: add missing newline to pr_warn
From: Sami Tolvanen @ 2026-05-29 1:05 UTC (permalink / raw)
To: Kenny Glowner
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Miguel Ojeda,
linux-modules, rust-for-linux, linux-kernel
In-Reply-To: <20260521161405.64042-1-SisyphusCode0311@gmail.com>
On Thu, May 21, 2026 at 11:14:05AM -0500, Kenny Glowner wrote:
> Add a trailing newline ('\n') to the pr_warn! call in set_param to
> ensure the kernel ring buffer flushes the message correctly and
> prevents log line smearing.
>
Applied to modules-next, thanks!
[1/1] rust: module_param: add missing newline to pr_warn_once
commit: ae12a56ba16adcb8a06d5b3b91d4f82a092e8de3
Best regards,
Sami
^ permalink raw reply
* Re: [PATCH v5 0/4] Enable sysfs module symlink for more built-in drivers
From: Danilo Krummrich @ 2026-05-28 21:19 UTC (permalink / raw)
To: Shashank Balaji, Suzuki K Poulose
Cc: James Clark, Alexander Shishkin, Greg Kroah-Hartman,
Rafael J. Wysocki, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Jonathan Corbet, Shuah Khan, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Mike Leach,
Leo Yan, Thierry Reding, Jonathan Hunter, Rahul Bukte,
linux-kernel, coresight, linux-arm-kernel, driver-core,
rust-for-linux, linux-doc, Daniel Palmer, Tim Bird, linux-modules,
linux-tegra, Sumit Gupta
In-Reply-To: <20260518-acpi_mod_name-v5-0-705ccc430885@sony.com>
On Mon May 18, 2026 at 12:19 PM CEST, Shashank Balaji wrote:
> Shashank Balaji (4):
> soc/tegra: cbb: Move driver registration from pure_initcall to core_initcall
> kernel: param: initialize module_kset in a pure_initcall
> coresight: pass THIS_MODULE implicitly through a macro
> driver core: platform: set mod_name in driver registration
I assume this goes through driver-core.
Suzuki, please let me know if that's fine with you for the coresight change.
Thanks,
Danilo
^ permalink raw reply
* Re: [PATCH v5 1/4] soc/tegra: cbb: Move driver registration from pure_initcall to core_initcall
From: Thierry Reding @ 2026-05-28 21:09 UTC (permalink / raw)
To: Shashank Balaji
Cc: Suzuki K Poulose, James Clark, Alexander Shishkin,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Jonathan Corbet, Shuah Khan, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Mike Leach, Leo Yan,
Jonathan Hunter, Rahul Bukte, linux-kernel, coresight,
linux-arm-kernel, driver-core, rust-for-linux, linux-doc,
Daniel Palmer, Tim Bird, linux-modules, linux-tegra, Sumit Gupta
In-Reply-To: <20260518-acpi_mod_name-v5-1-705ccc430885@sony.com>
[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]
On Mon, May 18, 2026 at 07:19:57PM +0900, Shashank Balaji wrote:
> Commit "driver core: platform: set mod_name in driver registration" will set
> struct device_driver's mod_name member for platform driver registration. For a
> driver to be registered with its mod_name set, module_kset needs to be
> initialized, which currently happens in a subsys_initcall in param_sysfs_init().
> The tegra cbb drivers register themselves before module_kset init, in a
> pure_initcall. This works currently because lookup_or_create_module_kobject(),
> which dereferences module_kset via kset_find_obj(), is not called if mod_name
> is not set, which is the case now.
>
> So in preparation for the commit "driver core: platform: set mod_name in driver registration",
> move tegra cbb driver registration to core_initcall level, and commit
> "kernel: param: initialize module_kset in a pure_initcall" will move module_kset
> init to pure_initcall level, ensuring module_kset init happens before tegra cbb
> driver registration.
>
> Suggested-by: Gary Guo <gary@garyguo.net>
> Acked-by: Sumit Gupta <sumitg@nvidia.com>
> Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
> ---
> Patch 4 depends on this patch
> ---
> drivers/soc/tegra/cbb/tegra194-cbb.c | 2 +-
> drivers/soc/tegra/cbb/tegra234-cbb.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Assuming you want to take this through the core driver tree:
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] rust: module_param: add missing newline to pr_warn
From: Sami Tolvanen @ 2026-05-28 20:35 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Kenny Glowner, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Miguel Ojeda, linux-modules, rust-for-linux, linux-kernel
In-Reply-To: <CANiq72m5GZp_p2HCgotBaevLmt1NrvzwrzJJK5sLUEwxeVLBdw@mail.gmail.com>
On Thu, May 28, 2026 at 1:56 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Thu, May 21, 2026 at 6:14 PM Kenny Glowner
> <sisyphuscode0311@gmail.com> wrote:
> >
> > Add a trailing newline ('\n') to the pr_warn! call in set_param to
> > ensure the kernel ring buffer flushes the message correctly and
> > prevents log line smearing.
>
> Did you see log smearing? IIRC this changed with the buffer rework --
> it is still the convention we expect, though, so the diff contents are
> good.
>
> > Link: https://github.com/Rust-for-Linux/linux/issues/1139
> >
> > Signed-off-by: Kenny Glowner <SisyphusCode0311@gmail.com>
>
> Andreas, Sami, Daniel, Luis, Petr: will this one go through modules
> too? Otherwise, please let me know and I can take it.
Yes, I'll take this one through modules too. Thanks, Miguel.
Sami
^ permalink raw reply
* Re: [PATCH 0/1] rust: module_param: support bool parameters
From: Andreas Hindborg @ 2026-05-28 13:15 UTC (permalink / raw)
To: Greg KH
Cc: Wenzhao Liao, mcgrof, petr.pavlu, da.gomez, samitolvanen, ojeda,
linux-modules, rust-for-linux, atomlin, boqun, gary, bjorn3_gh,
lossin, aliceryhl, tmgross, dakr, linux-kernel
In-Reply-To: <2026041323-fled-sharply-77c0@gregkh>
Greg KH <greg@kroah.com> writes:
> On Mon, Apr 13, 2026 at 02:00:17PM +0200, Andreas Hindborg wrote:
>> "Greg KH" <greg@kroah.com> writes:
>>
>> > 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.
>>
>> Rust null block uses module parameters, and was requested to use proper
>> boolean parsing rather than overloading u8 parsing for boolean
>> parameters [1].
>>
>> Best regards,
>> Andreas Hindborg
>>
>>
>> [1] https://lore.kernel.org/rust-for-linux/abfK4eji5jKSeO_W@google.com/
>>
>
> Ok, then that needs to be said somewhere, and ideally, have the code
> that uses that as part of the patch series.
It should be mentioned for sure, with a link to the code. I'm not sure
including this patch in the rnull driver series is the right approach.
That series is a really long already. I think using the b4 dependency
feature for dependencies is a better approach for marking dependencies.
I understand that you want to see APIs in context of use, that makes
sense.
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH] ARM: module.lds: fix unwind metadata for merged .text sections
From: Petr Pavlu @ 2026-05-28 12:44 UTC (permalink / raw)
To: Egg12138
Cc: Russell King, Josh Poimboeuf, Petr Mladek, linux-arm-kernel,
linux-modules, linux-kernel
In-Reply-To: <tencent_69DC6E2A5B77E4D567CA4F552DD3A835590A@qq.com>
On 5/21/26 5:57 PM, Egg12138 wrote:
> Commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN,
> and related macros") made scripts/module.lds.S merge module input
> .text.* sections into the output .text section.
>
> On ARM, the paired unwind input sections keep their original names. A
> module can therefore contain .ARM.exidx.text.unlikely with sh_link
> pointing at .text, while .text.unlikely no longer exists.
>
> This is a valid ELF relationship, but ARM module_finalize() does not use
> sh_link when registering module unwind tables. It derives the target
> text section from the exidx section name instead:
>
> .ARM.exidx.text.unlikely -> .text.unlikely
>
> The lookup fails and the unwind table is not registered for the actual
> .text range. This can make module stack unwinding fail with:
>
> unwind: Index not found
>
> Keep the ARM module unwind output names in sync with the text sections
> that scripts/module.lds.S now produces. Coalesce the .ARM.exidx/.ARM.extab
> sections associated with .text.*, into the
> stable output names expected by the existing ARM module unwind code.
>
> Fixes: 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros")
> Signed-off-by: Egg12138 <egg12138@foxmail.com>
A Signed-off-by tag should use a known identity, see
Documentation/process/submitting-patches.rst, Developer's Certificate of
Origin 1.1 [1].
> ---
> arch/arm/include/asm/module.lds.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/include/asm/module.lds.h b/arch/arm/include/asm/module.lds.h
> index 0e7cb4e314b4..dc9adf8fa50e 100644
> --- a/arch/arm/include/asm/module.lds.h
> +++ b/arch/arm/include/asm/module.lds.h
> @@ -1,4 +1,12 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef CONFIG_ARCH_WANTS_MODULES_TEXT_SECTIONS
The Arm architecture support doesn't select
CONFIG_ARCH_WANTS_MODULES_TEXT_SECTIONS, so this #ifndef is not really
necessary. I suggest leaving these linker definitions unconditional, or
alternatively use '#ifdef CONFIG_ARM_UNWIND'.
> +SECTIONS {
> + .ARM.extab 0 : { *(.ARM.extab .ARM.extab.text .ARM.extab.text.[0-9a-zA-Z_]*) }
> + .ARM.exidx 0 : { *(.ARM.exidx .ARM.exidx.text .ARM.exidx.text.[0-9a-zA-Z_]*) }
> +}
> +#endif
> +
> #ifdef CONFIG_ARM_MODULE_PLTS
> SECTIONS {
> .plt : { BYTE(0) }
Besides the above nits, the patch looks ok to me. Please don't forget to
put it in Russell's patch tracker [2].
[1] https://github.com/torvalds/linux/blob/v7.1-rc5/Documentation/process/submitting-patches.rst#developers-certificate-of-origin-11
[2] https://www.arm.linux.org.uk/developer/patches/
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH] rust: module_param: add missing newline to pr_warn
From: Miguel Ojeda @ 2026-05-28 8:59 UTC (permalink / raw)
To: Kenny Glowner
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Miguel Ojeda, linux-modules, rust-for-linux, linux-kernel
In-Reply-To: <20260521161405.64042-1-SisyphusCode0311@gmail.com>
On Thu, May 21, 2026 at 6:14 PM Kenny Glowner
<sisyphuscode0311@gmail.com> wrote:
>
> Link: https://github.com/Rust-for-Linux/linux/issues/1139
>
> Signed-off-by: Kenny Glowner <SisyphusCode0311@gmail.com>
By the way, we put tags together as one -- also please feel free to
add me as suggester like the issue says (part of the reason behind
these "good first issues" is to show you how these tags usually work),
e.g.
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1139
Signed-off-by: Kenny Glowner <SisyphusCode0311@gmail.com>
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] rust: module_param: add missing newline to pr_warn
From: Miguel Ojeda @ 2026-05-28 8:56 UTC (permalink / raw)
To: Kenny Glowner
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Miguel Ojeda, linux-modules, rust-for-linux, linux-kernel
In-Reply-To: <20260521161405.64042-1-SisyphusCode0311@gmail.com>
On Thu, May 21, 2026 at 6:14 PM Kenny Glowner
<sisyphuscode0311@gmail.com> wrote:
>
> Add a trailing newline ('\n') to the pr_warn! call in set_param to
> ensure the kernel ring buffer flushes the message correctly and
> prevents log line smearing.
Did you see log smearing? IIRC this changed with the buffer rework --
it is still the convention we expect, though, so the diff contents are
good.
> Link: https://github.com/Rust-for-Linux/linux/issues/1139
>
> Signed-off-by: Kenny Glowner <SisyphusCode0311@gmail.com>
Andreas, Sami, Daniel, Luis, Petr: will this one go through modules
too? Otherwise, please let me know and I can take it.
(Trivial conflict with the `pr_warn_once!` one applied yesterday.)
Thanks!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2] module: decompress: check return value of module_extend_max_pages()
From: Sami Tolvanen @ 2026-05-27 22:58 UTC (permalink / raw)
To: Afi0; +Cc: linux-modules, chleroy, mcgrof, dmitry.torokhov, linux-kernel,
stable
In-Reply-To: <CAEABq7e5NT0c58gG=fqFK-RmfrgUDA-8jXnmMMQZHMNu4hea5Q@mail.gmail.com>
On Wed, May 20, 2026 at 04:05:11PM +0000, Afi0 wrote:
> Thanks for the correction. Updated commit message
Please follow submitting-patches instructions next time. I used
the v3 commit message and changed the Fixes tag hash to point to
the correct commit.
Applied to modules-next, thanks!
[1/1] module: decompress: check return value of module_extend_max_pages()
commit: 3537d8d21112c2fc664cc09895bbef01fa64d34f
Best regards,
Sami
^ permalink raw reply
* Re: [PATCH v5 2/4] kernel: param: initialize module_kset in a pure_initcall
From: Gary Guo @ 2026-05-27 11:19 UTC (permalink / raw)
To: Shashank Balaji, Suzuki K Poulose, James Clark,
Alexander Shishkin, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Jonathan Corbet, Shuah Khan, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Mike Leach,
Leo Yan, Thierry Reding, Jonathan Hunter
Cc: Rahul Bukte, linux-kernel, coresight, linux-arm-kernel,
driver-core, rust-for-linux, linux-doc, Daniel Palmer, Tim Bird,
linux-modules, linux-tegra, Sumit Gupta
In-Reply-To: <20260518-acpi_mod_name-v5-2-705ccc430885@sony.com>
On Mon May 18, 2026 at 11:19 AM BST, Shashank Balaji wrote:
> Commit "driver core: platform: set mod_name in driver registration" will set
> struct device_driver's mod_name member for platform driver registration. For a
> driver to be registered with its mod_name set, module_kset needs to be
> initialized, which currently happens in a subsys_initcall in param_sysfs_init().
> The tegra cbb drivers register themselves before module_kset init, in a
> core_initcall. This works currently because lookup_or_create_module_kobject(),
> which dereferences module_kset via kset_find_obj(), is not called if mod_name
> is not set, which is the case now.
>
> So in preparation for the commit "driver core: platform: set mod_name in driver registration",
> move module_kset init to pure_initcall level, ensuring it happens before tegra
> cbb driver registration.
>
> Suggested-by: Gary Guo <gary@garyguo.net>
> Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Patch 4 depends on this patch
> ---
> kernel/params.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH v5 1/4] soc/tegra: cbb: Move driver registration from pure_initcall to core_initcall
From: Gary Guo @ 2026-05-27 11:19 UTC (permalink / raw)
To: Shashank Balaji, Suzuki K Poulose, James Clark,
Alexander Shishkin, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Jonathan Corbet, Shuah Khan, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Mike Leach,
Leo Yan, Thierry Reding, Jonathan Hunter
Cc: Rahul Bukte, linux-kernel, coresight, linux-arm-kernel,
driver-core, rust-for-linux, linux-doc, Daniel Palmer, Tim Bird,
linux-modules, linux-tegra, Sumit Gupta
In-Reply-To: <20260518-acpi_mod_name-v5-1-705ccc430885@sony.com>
On Mon May 18, 2026 at 11:19 AM BST, Shashank Balaji wrote:
> Commit "driver core: platform: set mod_name in driver registration" will set
> struct device_driver's mod_name member for platform driver registration. For a
> driver to be registered with its mod_name set, module_kset needs to be
> initialized, which currently happens in a subsys_initcall in param_sysfs_init().
> The tegra cbb drivers register themselves before module_kset init, in a
> pure_initcall. This works currently because lookup_or_create_module_kobject(),
> which dereferences module_kset via kset_find_obj(), is not called if mod_name
> is not set, which is the case now.
>
> So in preparation for the commit "driver core: platform: set mod_name in driver registration",
> move tegra cbb driver registration to core_initcall level, and commit
> "kernel: param: initialize module_kset in a pure_initcall" will move module_kset
> init to pure_initcall level, ensuring module_kset init happens before tegra cbb
> driver registration.
>
> Suggested-by: Gary Guo <gary@garyguo.net>
> Acked-by: Sumit Gupta <sumitg@nvidia.com>
> Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Patch 4 depends on this patch
> ---
> drivers/soc/tegra/cbb/tegra194-cbb.c | 2 +-
> drivers/soc/tegra/cbb/tegra234-cbb.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH] rust: module_param: use `pr_warn_once!` for null pointer warning
From: Sami Tolvanen @ 2026-05-26 23:59 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Aaron Tomlin,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Andreas Hindborg, linux-modules, linux-kernel, rust-for-linux
In-Reply-To: <CANiq72nq45d+kvyR8jp-hdJhFHv-zw2i51mPCduBeUdgSwMKsA@mail.gmail.com>
On Tue, May 26, 2026 at 4:46 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Wed, May 27, 2026 at 1:40 AM Sami Tolvanen <samitolvanen@google.com> wrote:
> >
> > Applied to modules-next, thanks!
> >
> > [1/1] rust: module_param: use `pr_warn_once!` for null pointer warning
> > commit: 8d2a562b7efe98fdea57d10caaced911fca46a3f
>
> Even if we pick this one, should we credit Adarsh Das?
>
> https://lore.kernel.org/rust-for-linux/20260226120848.82891-3-adarshdas950@gmail.com/
>
> Or did Andreas send it earlier than that?
Ah, that series was never sent to linux-modules, so it wasn't on my
list. I agree that Adarsh seems to have sent the same patch first
though. Happy to credit him unless someone objects.
Sami
^ permalink raw reply
* Re: [PATCH] rust: module_param: use `pr_warn_once!` for null pointer warning
From: Miguel Ojeda @ 2026-05-26 23:46 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Aaron Tomlin,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Andreas Hindborg, linux-modules, linux-kernel, rust-for-linux
In-Reply-To: <177983883957.35274.15506019019254966722.b4-ty@google.com>
On Wed, May 27, 2026 at 1:40 AM Sami Tolvanen <samitolvanen@google.com> wrote:
>
> Applied to modules-next, thanks!
>
> [1/1] rust: module_param: use `pr_warn_once!` for null pointer warning
> commit: 8d2a562b7efe98fdea57d10caaced911fca46a3f
Even if we pick this one, should we credit Adarsh Das?
https://lore.kernel.org/rust-for-linux/20260226120848.82891-3-adarshdas950@gmail.com/
Or did Andreas send it earlier than that?
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] rust: module_param: use `pr_warn_once!` for null pointer warning
From: Sami Tolvanen @ 2026-05-26 23:40 UTC (permalink / raw)
To: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Aaron Tomlin,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Andreas Hindborg
Cc: linux-modules, linux-kernel, rust-for-linux
In-Reply-To: <20260427-params-pr-once-v1-1-3a8c64704cc4@kernel.org>
On Mon, 27 Apr 2026 10:11:35 +0200, Andreas Hindborg wrote:
> Replace `pr_warn!` and the accompanying TODO with `pr_warn_once!`, now that
> the macro is available.
>
>
Applied to modules-next, thanks!
[1/1] rust: module_param: use `pr_warn_once!` for null pointer warning
commit: 8d2a562b7efe98fdea57d10caaced911fca46a3f
Best regards,
Sami
^ permalink raw reply
* Re: [PATCH 0/4] module: force sh_addr=0 for arch-specific sections
From: Sami Tolvanen @ 2026-05-26 23:40 UTC (permalink / raw)
To: Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Petr Pavlu
Cc: Alexandre Ghiti, Luis Chamberlain, Daniel Gomez, Aaron Tomlin,
Joe Lawrence, linux-arm-kernel, linux-m68k, linux-riscv,
linux-modules, linux-kernel
In-Reply-To: <20260327080023.861105-1-petr.pavlu@suse.com>
On Fri, 27 Mar 2026 08:58:59 +0100, Petr Pavlu wrote:
> When linking modules with 'ld.bfd -r', sections defined without an address
> inherit the location counter, resulting in non-zero sh_addr values in the
> resulting .ko files. Relocatable objects are expected to have sh_addr=0 for
> all sections. Non-zero addresses are confusing in this context, typically
> worse compressible, and may cause tools to misbehave [1].
>
> Joe Lawrence previously addressed the same issue in the main
> scripts/module.lds.S file [2] and we discussed that the same fix should be
> also applied to architecture-specific module sections. This series
> implements these changes.
>
> [...]
Applied to modules-next, thanks!
[1/4] module, arm: force sh_addr=0 for arch-specific sections
commit: ffe1545ce8a0a7bb698d5f68cbbdef8f93d1fce6
[2/4] module, arm64: force sh_addr=0 for arch-specific sections
commit: c5553deb577fe433f770e270fd9582b8325f12d9
[3/4] module, m68k: force sh_addr=0 for arch-specific sections
commit: 9cb4d4dc82272538de1b7edb6e8cf91597ed00b0
[4/4] module, riscv: force sh_addr=0 for arch-specific sections
commit: 04e17ca3f77e1722a5db068fbcd7b93c51656013
Best regards,
Sami
^ permalink raw reply
* Re: [PATCH v2] genksyms: Support arm64 CRC32 hardware acceleration1~
From: Wentao Guan @ 2026-05-26 19:13 UTC (permalink / raw)
To: Petr Pavlu; +Cc: linux-kbuild, linux-kernel, linux-modules, masahiroy
In-Reply-To: <c135351a-d7cc-467b-a0c0-bea735fe850a@suse.com>
Hello Petr,
> On 5/25/26 3:41 PM, Wentao Guan wrote:
> >> On 5/25/26 10:02 AM, Wentao Guan wrote:
> >>>> Additionally, many distributions already switched to gendwarfksyms last
> >>>> year. Unless someone provides a good reason to keep genksyms around,
> >>>> I expect it will be deprecated soon and eventually removed. It would be
> >>>> more valuable to show whether the same optimization is worthwhile for
> >>>> gendwarfksyms.
> >>> I see gendwarfksyms use crc32 from <zlib.h>, which from zlib1g-dev and zlib1g.
> >>
> >> Ah, I forgot about this, so gendwarfksyms should already be well
> >> optimized. I think that is the most important thing.
> >
> > Which way do you prefer? There are two ways now:
> > 1. this work,
> > 2. import zlib like gendwarfksyms and remove the huge crctab,
> > but need make sure any arch do not cause performance regression?
> > (Assert the user libs precompile with +crc32 is right?)
> > I do some early tests show that:
> > 1) zlib in x86 fast than genksym software
> > 2) zlib in arm64 debian precompile slow than genksym software(crc32 not in armv8)
> > 3) zlib in arm64 recompile with +crc32 same speed with genksyms hardware
>
> I think it would be useful to first have more data showing that the CRC
> calculation in genksyms is a hot path and contributes significantly to
> the overall kernel build time.
I found that 'nm' is slow and a really crazy but significantly improve my build speed,
from 11m50s down to 11m18s:
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 0c838c467..d5b9db6d3 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -231,7 +231,7 @@ ifdef CONFIG_MODVERSIONS
# be compiled and linked to the kernel and/or modules.
gen_symversions = \
- if $(NM) $@ 2>/dev/null | grep -q ' __export_symbol_'; then \
+ if strings $@ 2>/dev/null | grep -q '__export_symbol_'; then \
$(cmd_gensymtypes_$1) >> $(dot-target).cmd; \
fi
BRs
Wentao Guan
^ permalink raw reply related
* Re: [PATCH v2] genksyms: Support arm64 CRC32 hardware acceleration1~
From: Wentao Guan @ 2026-05-26 18:12 UTC (permalink / raw)
To: Petr Pavlu; +Cc: linux-kbuild, linux-kernel, linux-modules, masahiroy
In-Reply-To: <c135351a-d7cc-467b-a0c0-bea735fe850a@suse.com>
Hello Petr,
> On 5/25/26 3:41 PM, Wentao Guan wrote:
>>> On 5/25/26 10:02 AM, Wentao Guan wrote:
>>>>> Additionally, many distributions already switched to gendwarfksyms last
>>>>> year. Unless someone provides a good reason to keep genksyms around,
>>>>> I expect it will be deprecated soon and eventually removed. It would be
>>>>> more valuable to show whether the same optimization is worthwhile for
>>>>> gendwarfksyms.
>>>> I see gendwarfksyms use crc32 from <zlib.h>, which from zlib1g-dev and zlib1g.
>>>
>>> Ah, I forgot about this, so gendwarfksyms should already be well
>>> optimized. I think that is the most important thing.
>>
>> Which way do you prefer? There are two ways now:
>> 1. this work,
>> 2. import zlib like gendwarfksyms and remove the huge crctab,
>> but need make sure any arch do not cause performance regression?
>> (Assert the user libs precompile with +crc32 is right?)
>> I do some early tests show that:
>> 1) zlib in x86 fast than genksym software
>> 2) zlib in arm64 debian precompile slow than genksym software(crc32 not in armv8)
>> 3) zlib in arm64 recompile with +crc32 same speed with genksyms hardware
>
> I think it would be useful to first have more data showing that the CRC
> calculation in genksyms is a hot path and contributes significantly to
> the overall kernel build time.
You are right.
1. genksyms contributes significantly to the overall kernel build time.
Test with arm64 defconfig and enable/disable CONFIG_GENKSYMS (11m50s/9m48s)
2. crc32 shows ~10% affect in perf record w/o patch.
3. but this patch w/o doesn`t affect the overall kernel build time 11m50s(+-1s).
4. so try to use zlib and delete the hard code crctab32 table?
BRs
Wentao Guan
RFC PATCH:
From f8f1c2301ddb70fb42a56fd7228db3dbd248e2b4 Mon Sep 17 00:00:00 2001
From: Wentao Guan <guanwentao@uniontech.com>
Date: Mon, 25 May 2026 20:02:03 +0800
Subject: [PATCH] genksyms: use crc32 from zlib
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
---
scripts/genksyms/Makefile | 1 +
scripts/genksyms/genksyms.c | 70 +++++--------------------------------
2 files changed, 9 insertions(+), 62 deletions(-)
diff --git a/scripts/genksyms/Makefile b/scripts/genksyms/Makefile
index 4350311fb7b39..068e79626ffe7 100644
--- a/scripts/genksyms/Makefile
+++ b/scripts/genksyms/Makefile
@@ -7,6 +7,7 @@ genksyms-objs := genksyms.o parse.tab.o lex.lex.o
# -I needed for generated C source to include headers in source tree
HOSTCFLAGS_parse.tab.o := -I $(src)
HOSTCFLAGS_lex.lex.o := -I $(src)
+HOSTLDLIBS_genksyms := -lz
# dependencies on generated files need to be listed explicitly
$(obj)/lex.lex.o: $(obj)/parse.tab.h
diff --git a/scripts/genksyms/genksyms.c b/scripts/genksyms/genksyms.c
index 83e48670c2fcf..40d25dd898874 100644
--- a/scripts/genksyms/genksyms.c
+++ b/scripts/genksyms/genksyms.c
@@ -20,6 +20,7 @@
#include <getopt.h>
#include <hashtable.h>
+#include <zlib.h>
#include "genksyms.h"
/*----------------------------------------------------------------------*/
@@ -61,78 +62,23 @@ static void print_type_name(enum symbol_type type, const char *name);
/*----------------------------------------------------------------------*/
-static const uint32_t crctab32[] = {
- 0x00000000U, 0x77073096U, 0xee0e612cU, 0x990951baU, 0x076dc419U,
- 0x706af48fU, 0xe963a535U, 0x9e6495a3U, 0x0edb8832U, 0x79dcb8a4U,
- 0xe0d5e91eU, 0x97d2d988U, 0x09b64c2bU, 0x7eb17cbdU, 0xe7b82d07U,
- 0x90bf1d91U, 0x1db71064U, 0x6ab020f2U, 0xf3b97148U, 0x84be41deU,
- 0x1adad47dU, 0x6ddde4ebU, 0xf4d4b551U, 0x83d385c7U, 0x136c9856U,
- 0x646ba8c0U, 0xfd62f97aU, 0x8a65c9ecU, 0x14015c4fU, 0x63066cd9U,
- 0xfa0f3d63U, 0x8d080df5U, 0x3b6e20c8U, 0x4c69105eU, 0xd56041e4U,
- 0xa2677172U, 0x3c03e4d1U, 0x4b04d447U, 0xd20d85fdU, 0xa50ab56bU,
- 0x35b5a8faU, 0x42b2986cU, 0xdbbbc9d6U, 0xacbcf940U, 0x32d86ce3U,
- 0x45df5c75U, 0xdcd60dcfU, 0xabd13d59U, 0x26d930acU, 0x51de003aU,
- 0xc8d75180U, 0xbfd06116U, 0x21b4f4b5U, 0x56b3c423U, 0xcfba9599U,
- 0xb8bda50fU, 0x2802b89eU, 0x5f058808U, 0xc60cd9b2U, 0xb10be924U,
- 0x2f6f7c87U, 0x58684c11U, 0xc1611dabU, 0xb6662d3dU, 0x76dc4190U,
- 0x01db7106U, 0x98d220bcU, 0xefd5102aU, 0x71b18589U, 0x06b6b51fU,
- 0x9fbfe4a5U, 0xe8b8d433U, 0x7807c9a2U, 0x0f00f934U, 0x9609a88eU,
- 0xe10e9818U, 0x7f6a0dbbU, 0x086d3d2dU, 0x91646c97U, 0xe6635c01U,
- 0x6b6b51f4U, 0x1c6c6162U, 0x856530d8U, 0xf262004eU, 0x6c0695edU,
- 0x1b01a57bU, 0x8208f4c1U, 0xf50fc457U, 0x65b0d9c6U, 0x12b7e950U,
- 0x8bbeb8eaU, 0xfcb9887cU, 0x62dd1ddfU, 0x15da2d49U, 0x8cd37cf3U,
- 0xfbd44c65U, 0x4db26158U, 0x3ab551ceU, 0xa3bc0074U, 0xd4bb30e2U,
- 0x4adfa541U, 0x3dd895d7U, 0xa4d1c46dU, 0xd3d6f4fbU, 0x4369e96aU,
- 0x346ed9fcU, 0xad678846U, 0xda60b8d0U, 0x44042d73U, 0x33031de5U,
- 0xaa0a4c5fU, 0xdd0d7cc9U, 0x5005713cU, 0x270241aaU, 0xbe0b1010U,
- 0xc90c2086U, 0x5768b525U, 0x206f85b3U, 0xb966d409U, 0xce61e49fU,
- 0x5edef90eU, 0x29d9c998U, 0xb0d09822U, 0xc7d7a8b4U, 0x59b33d17U,
- 0x2eb40d81U, 0xb7bd5c3bU, 0xc0ba6cadU, 0xedb88320U, 0x9abfb3b6U,
- 0x03b6e20cU, 0x74b1d29aU, 0xead54739U, 0x9dd277afU, 0x04db2615U,
- 0x73dc1683U, 0xe3630b12U, 0x94643b84U, 0x0d6d6a3eU, 0x7a6a5aa8U,
- 0xe40ecf0bU, 0x9309ff9dU, 0x0a00ae27U, 0x7d079eb1U, 0xf00f9344U,
- 0x8708a3d2U, 0x1e01f268U, 0x6906c2feU, 0xf762575dU, 0x806567cbU,
- 0x196c3671U, 0x6e6b06e7U, 0xfed41b76U, 0x89d32be0U, 0x10da7a5aU,
- 0x67dd4accU, 0xf9b9df6fU, 0x8ebeeff9U, 0x17b7be43U, 0x60b08ed5U,
- 0xd6d6a3e8U, 0xa1d1937eU, 0x38d8c2c4U, 0x4fdff252U, 0xd1bb67f1U,
- 0xa6bc5767U, 0x3fb506ddU, 0x48b2364bU, 0xd80d2bdaU, 0xaf0a1b4cU,
- 0x36034af6U, 0x41047a60U, 0xdf60efc3U, 0xa867df55U, 0x316e8eefU,
- 0x4669be79U, 0xcb61b38cU, 0xbc66831aU, 0x256fd2a0U, 0x5268e236U,
- 0xcc0c7795U, 0xbb0b4703U, 0x220216b9U, 0x5505262fU, 0xc5ba3bbeU,
- 0xb2bd0b28U, 0x2bb45a92U, 0x5cb36a04U, 0xc2d7ffa7U, 0xb5d0cf31U,
- 0x2cd99e8bU, 0x5bdeae1dU, 0x9b64c2b0U, 0xec63f226U, 0x756aa39cU,
- 0x026d930aU, 0x9c0906a9U, 0xeb0e363fU, 0x72076785U, 0x05005713U,
- 0x95bf4a82U, 0xe2b87a14U, 0x7bb12baeU, 0x0cb61b38U, 0x92d28e9bU,
- 0xe5d5be0dU, 0x7cdcefb7U, 0x0bdbdf21U, 0x86d3d2d4U, 0xf1d4e242U,
- 0x68ddb3f8U, 0x1fda836eU, 0x81be16cdU, 0xf6b9265bU, 0x6fb077e1U,
- 0x18b74777U, 0x88085ae6U, 0xff0f6a70U, 0x66063bcaU, 0x11010b5cU,
- 0x8f659effU, 0xf862ae69U, 0x616bffd3U, 0x166ccf45U, 0xa00ae278U,
- 0xd70dd2eeU, 0x4e048354U, 0x3903b3c2U, 0xa7672661U, 0xd06016f7U,
- 0x4969474dU, 0x3e6e77dbU, 0xaed16a4aU, 0xd9d65adcU, 0x40df0b66U,
- 0x37d83bf0U, 0xa9bcae53U, 0xdebb9ec5U, 0x47b2cf7fU, 0x30b5ffe9U,
- 0xbdbdf21cU, 0xcabac28aU, 0x53b39330U, 0x24b4a3a6U, 0xbad03605U,
- 0xcdd70693U, 0x54de5729U, 0x23d967bfU, 0xb3667a2eU, 0xc4614ab8U,
- 0x5d681b02U, 0x2a6f2b94U, 0xb40bbe37U, 0xc30c8ea1U, 0x5a05df1bU,
- 0x2d02ef8dU
-};
static uint32_t partial_crc32_one(uint8_t c, uint32_t crc)
{
- return crctab32[(crc ^ c) & 0xff] ^ (crc >> 8);
+ return crc32(crc ^ 0xffffffff, (const unsigned char *)&c, 1) ^ 0xffffffff;
}
static uint32_t partial_crc32(const char *s, uint32_t crc)
{
- while (*s)
- crc = partial_crc32_one(*s++, crc);
- return crc;
+ return crc32(crc ^ 0xffffffff, (const unsigned char *)s, strlen(s)) ^ 0xffffffff;
}
-static uint32_t crc32(const char *s)
+static uint32_t crc32_name(const char *s)
{
- return partial_crc32(s, 0xffffffff) ^ 0xffffffff;
+ return crc32(0, (const unsigned char *)s, strlen(s));
}
+
/*----------------------------------------------------------------------*/
static enum symbol_type map_to_ns(enum symbol_type t)
@@ -154,7 +100,7 @@ struct symbol *find_symbol(const char *name, enum symbol_type ns, int exact)
{
struct symbol *sym;
- hash_for_each_possible(symbol_hashtable, sym, hnode, crc32(name)) {
+ hash_for_each_possible(symbol_hashtable, sym, hnode, crc32_name(name)) {
if (map_to_ns(sym->type) == map_to_ns(ns) &&
strcmp(name, sym->name) == 0 &&
sym->is_declared)
@@ -238,7 +184,7 @@ static struct symbol *__add_symbol(const char *name, enum symbol_type type,
return NULL;
}
- h = crc32(name);
+ h = crc32_name(name);
hash_for_each_possible(symbol_hashtable, sym, hnode, h) {
if (map_to_ns(sym->type) != map_to_ns(type) ||
strcmp(name, sym->name))
--
2.30.2
^ permalink raw reply related
* Re: build failure for stablerc
From: Toralf Förster @ 2026-05-26 17:17 UTC (permalink / raw)
To: Petr Pavlu; +Cc: linux-modules, linux-kbuild, Linux Kernel
In-Reply-To: <a4ac44fa-146b-4b13-bf42-0c8cff601ed2@suse.com>
On 26/05/2026 09:31, Petr Pavlu wrote:
> Gendwarfksyms requires libdw, see Documentation/kbuild/gendwarfksyms.rst
> [1]. Is the library and its development files installed on your system?
That was it - I've to install libdw-dev under Ubuntu-26.04.
Thx.
--
Toralf
^ permalink raw reply
* Re: [PATCH v5 10/14] module: Prepare for additional module authentication mechanisms
From: Petr Pavlu @ 2026-05-26 13:14 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Nathan Chancellor,
Nicolas Schier, Arnd Bergmann, Luis Chamberlain, Sami Tolvanen,
Daniel Gomez, Paul Moore, James Morris, Serge E. Hallyn,
Jonathan Corbet, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Naveen N Rao, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Nicolas Schier, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Martin KaFai Lau, Song Liu, Yonghong Song,
Jiri Olsa, bpf, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Eric Biggers, Sebastian Andrzej Siewior, linux-kbuild,
linux-kernel, linux-arch, linux-modules, linux-security-module,
linux-doc, linuxppc-dev, linux-integrity, debian-kernel
In-Reply-To: <20260505-module-hashes-v5-10-e174a5a49fce@weissschuh.net>
On 5/5/26 11:05 AM, Thomas Weißschuh wrote:
> Reorganize the code to make it easier to add the new hash-based module
> authentication.
>
> Also drop the now unnecessary stub for module_sig_check().
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
-- Petr
^ permalink raw reply
* Re: [PATCH v5 09/14] module: Move signature type check out of mod_check_sig()
From: Petr Pavlu @ 2026-05-26 13:03 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Nathan Chancellor,
Nicolas Schier, Arnd Bergmann, Luis Chamberlain, Sami Tolvanen,
Daniel Gomez, Paul Moore, James Morris, Serge E. Hallyn,
Jonathan Corbet, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Naveen N Rao, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Nicolas Schier, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Martin KaFai Lau, Song Liu, Yonghong Song,
Jiri Olsa, bpf, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Eric Biggers, Sebastian Andrzej Siewior, linux-kbuild,
linux-kernel, linux-arch, linux-modules, linux-security-module,
linux-doc, linuxppc-dev, linux-integrity, debian-kernel
In-Reply-To: <20260505-module-hashes-v5-9-e174a5a49fce@weissschuh.net>
On 5/5/26 11:05 AM, Thomas Weißschuh wrote:
> Additional signature types are about to be added.
> As each caller of mod_check_sig() can have different support for these,
> move the type validation into the callers.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
-- Petr
^ permalink raw reply
* Re: [PATCH v5 07/14] module: Make module authentication usable without MODULE_SIG
From: kpcyrd @ 2026-05-26 12:27 UTC (permalink / raw)
To: Thomas Weißschuh, Petr Pavlu
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Nathan Chancellor,
Nicolas Schier, Arnd Bergmann, Luis Chamberlain, Sami Tolvanen,
Daniel Gomez, Paul Moore, James Morris, Serge E. Hallyn,
Jonathan Corbet, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Naveen N Rao, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Nicolas Schier, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Martin KaFai Lau, Song Liu, Yonghong Song,
Jiri Olsa, bpf, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, Christian Heusel, Câju Mihai-Drosi,
Eric Biggers, Sebastian Andrzej Siewior, linux-kbuild,
linux-kernel, linux-arch, linux-modules, linux-security-module,
linux-doc, linuxppc-dev, linux-integrity, debian-kernel,
Holger Levsen
In-Reply-To: <4ee3c775-1fbf-45e1-8b77-5f9034f45125@t-8ch.de>
On 5/26/26 1:38 PM, Thomas Weißschuh wrote:
> On 2026-05-26 12:53:22+0200, Petr Pavlu wrote:
>> Should MODULE_SIG_FORCE be renamed to MODULE_AUTH_FORCE, along with
>> renaming the sig_enforce functionality in kernel/module/auth.c to
>> auth_enforce?
>
> Given that it is a user-visible symbol we'll need to be a bit careful
> not to break existing configurations.
> I'll try to use the new "transitional" kconfig attribute.
A slightly softer worded alternative (yet semantically equivalent) name could be
MODULE_AUTH_REQUIRE. No strong opinion though, I think MODULE_AUTH_* does make
sense.
I initially shared the concern about renaming well established config options,
but the transitional feature does seem to be a good fit for this.
Sincerely,
kpcyrd
^ permalink raw reply
* Re: [PATCH v5 08/14] module: Move authentication logic into dedicated new file
From: Petr Pavlu @ 2026-05-26 11:58 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Nathan Chancellor,
Nicolas Schier, Arnd Bergmann, Luis Chamberlain, Sami Tolvanen,
Daniel Gomez, Paul Moore, James Morris, Serge E. Hallyn,
Jonathan Corbet, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Naveen N Rao, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Nicolas Schier, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Martin KaFai Lau, Song Liu, Yonghong Song,
Jiri Olsa, bpf, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Eric Biggers, Sebastian Andrzej Siewior, linux-kbuild,
linux-kernel, linux-arch, linux-modules, linux-security-module,
linux-doc, linuxppc-dev, linux-integrity, debian-kernel
In-Reply-To: <20260505-module-hashes-v5-8-e174a5a49fce@weissschuh.net>
On 5/5/26 11:05 AM, Thomas Weißschuh wrote:
> The module authentication functionality will also be used by the
> hash-based module authentication. To make it usable even if
> CONFIG_MODULE_SIG is disabled, move it to a new file.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> [...]
> diff --git a/kernel/module/auth.c b/kernel/module/auth.c
> index 956ac63d9d33..831a13eb0c9b 100644
> --- a/kernel/module/auth.c
> +++ b/kernel/module/auth.c
> @@ -5,10 +5,16 @@
> * Written by David Howells (dhowells@redhat.com)
> */
>
> +#include <linux/errno.h>
> #include <linux/export.h>
> #include <linux/module.h>
> +#include <linux/module_signature.h>
> #include <linux/moduleparam.h>
> +#include <linux/security.h>
> +#include <linux/string.h>
> #include <linux/types.h>
> +#include <uapi/linux/module.h>
> +#include "internal.h"
>
> #undef MODULE_PARAM_PREFIX
> #define MODULE_PARAM_PREFIX "module."
> @@ -30,3 +36,82 @@ void set_module_sig_enforced(void)
> {
> sig_enforce = true;
> }
> +
> +static int mod_verify_sig(const void *mod, struct load_info *info)
> +{
> + struct module_signature ms;
> + size_t sig_len, modlen = info->len;
> + int ret;
> +
> + if (modlen <= sizeof(ms))
> + return -EBADMSG;
> +
> + memcpy(&ms, mod + (modlen - sizeof(ms)), sizeof(ms));
> +
> + ret = mod_check_sig(&ms, modlen, "module");
> + if (ret)
> + return ret;
> +
> + sig_len = be32_to_cpu(ms.sig_len);
> + modlen -= sig_len + sizeof(ms);
> + info->len = modlen;
> +
> + return module_sig_check(mod, modlen, mod + modlen, sig_len);
> +}
> +
> +int module_auth_check(struct load_info *info, int flags)
> +{
> + int err = -ENODATA;
> + const unsigned long markerlen = sizeof(MODULE_SIGNATURE_MARKER) - 1;
> + const char *reason;
> + const void *mod = info->hdr;
> + bool mangled_module = flags & (MODULE_INIT_IGNORE_MODVERSIONS |
> + MODULE_INIT_IGNORE_VERMAGIC);
> + /*
> + * Do not allow mangled modules as a module with version information
> + * removed is no longer the module that was signed.
> + */
> + if (!mangled_module &&
> + info->len > markerlen &&
> + memcmp(mod + info->len - markerlen, MODULE_SIGNATURE_MARKER, markerlen) == 0) {
> + /* We truncate the module to discard the signature */
> + info->len -= markerlen;
> + err = mod_verify_sig(mod, info);
> + if (!err) {
> + info->auth_ok = true;
> + return 0;
> + }
> + }
> +
> + /*
> + * We don't permit modules to be loaded into the trusted kernels
> + * without a valid signature on them, but if we're not enforcing,
> + * certain errors are non-fatal.
> + */
> + switch (err) {
> + case -ENODATA:
> + reason = "unsigned module";
> + break;
> + case -ENOPKG:
> + reason = "module with unsupported crypto";
> + break;
> + case -ENOKEY:
> + reason = "module with unavailable key";
> + break;
> +
> + default:
> + /*
> + * All other errors are fatal, including lack of memory,
> + * unparseable signatures, and signature check failures --
> + * even if signatures aren't required.
> + */
> + return err;
> + }
> +
> + if (is_module_sig_enforced()) {
> + pr_notice("Loading of %s is rejected\n", reason);
> + return -EKEYREJECTED;
> + }
> +
> + return security_locked_down(LOCKDOWN_MODULE_SIGNATURE);
> +}
The resulting call chain of the module authentication/signature
functions is as follows:
ima_read_modsig() -----------------------------,
v
module_auth_check() -> mod_verify_sig() -> mod_check_sig()
|
|-> module_sig_check()
'-> module_hash_check()
I think this logic is quite hard to follow because mod_verify_sig(),
mod_check_sig() and module_sig_check() have very similar names.
The naming of module_auth_check(), module_sig_check() and
module_hash_check() looks good to me, but I would prefer to rename
mod_check_sig() and mod_verify_sig(). Perhaps mod_check_sig() could be
renamed to mod_check_sig_header(), and mod_verify_sig() to
mod_dispatch_auth_check()?
Otherwise, the patch looks ok to me. Feel free to add:
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH v5 07/14] module: Make module authentication usable without MODULE_SIG
From: Thomas Weißschuh @ 2026-05-26 11:38 UTC (permalink / raw)
To: Petr Pavlu
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Nathan Chancellor,
Nicolas Schier, Arnd Bergmann, Luis Chamberlain, Sami Tolvanen,
Daniel Gomez, Paul Moore, James Morris, Serge E. Hallyn,
Jonathan Corbet, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Naveen N Rao, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Nicolas Schier, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Martin KaFai Lau, Song Liu, Yonghong Song,
Jiri Olsa, bpf, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Eric Biggers, Sebastian Andrzej Siewior, linux-kbuild,
linux-kernel, linux-arch, linux-modules, linux-security-module,
linux-doc, linuxppc-dev, linux-integrity, debian-kernel
In-Reply-To: <0a0736a4-2cdd-49f2-9062-e2f18d769fc0@suse.com>
On 2026-05-26 12:53:22+0200, Petr Pavlu wrote:
> On 5/5/26 11:05 AM, Thomas Weißschuh wrote:
> > The module authentication functionality will also be used by the
> > hash-based module authentication. Split it out from CONFIG_MODULE_SIG
> > so it is usable by both.
> >
> > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> > [...]
> > diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
> > index f535181e0d98..84297da666ff 100644
> > --- a/kernel/module/Kconfig
> > +++ b/kernel/module/Kconfig
> > @@ -271,9 +271,12 @@ config MODULE_SIG
> > debuginfo strip done by some packagers (such as rpmbuild) and
> > inclusion into an initramfs that wants the module size reduced.
> >
> > +config MODULE_AUTH
> > + def_bool MODULE_SIG
> > +
> > config MODULE_SIG_FORCE
> > bool "Require modules to be validly signed"
> > - depends on MODULE_SIG
> > + depends on MODULE_AUTH
> > help
> > Reject unsigned modules or signed modules for which we don't have a
> > key. Without this, such modules will simply taint the kernel.
>
> Should MODULE_SIG_FORCE be renamed to MODULE_AUTH_FORCE, along with
> renaming the sig_enforce functionality in kernel/module/auth.c to
> auth_enforce?
Given that it is a user-visible symbol we'll need to be a bit careful
not to break existing configurations.
I'll try to use the new "transitional" kconfig attribute.
Thomas
^ permalink raw reply
* Re: [PATCH v5 06/14] module: Switch load_info::len to size_t
From: Thomas Weißschuh @ 2026-05-26 11:35 UTC (permalink / raw)
To: Petr Pavlu
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Nathan Chancellor,
Nicolas Schier, Arnd Bergmann, Luis Chamberlain, Sami Tolvanen,
Daniel Gomez, Paul Moore, James Morris, Serge E. Hallyn,
Jonathan Corbet, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Naveen N Rao, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Nicolas Schier, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Martin KaFai Lau, Song Liu, Yonghong Song,
Jiri Olsa, bpf, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Eric Biggers, Sebastian Andrzej Siewior, linux-kbuild,
linux-kernel, linux-arch, linux-modules, linux-security-module,
linux-doc, linuxppc-dev, linux-integrity, debian-kernel
In-Reply-To: <8de0e6ad-987a-4729-bbd0-8399968dbb48@suse.com>
On 2026-05-26 11:47:09+0200, Petr Pavlu wrote:
> On 5/5/26 11:05 AM, Thomas Weißschuh wrote:
> > Switching the types will make some later changes cleaner.
>
> Since the updated version drops the patch "module: Deduplicate signature
> extraction", I believe this change is no longer necessary.
Ack.
(...)
Thomas
^ 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