* Re: [PATCH v18 0/7] rust: extend `module!` macro with integer parameter support
From: Uwe Kleine-König @ 2025-11-02 9:56 UTC (permalink / raw)
To: Daniel Gomez
Cc: Andreas Hindborg, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Alice Ryhl, Masahiro Yamada,
Nathan Chancellor, Luis Chamberlain, Danilo Krummrich,
Benno Lossin, Nicolas Schier, Michal Wilczynski, Trevor Gross,
Adam Bratschi-Kaye, rust-for-linux, linux-kernel, linux-kbuild,
Petr Pavlu, Sami Tolvanen, Daniel Gomez, Simona Vetter, Greg KH,
Fiona Behrens, Daniel Almeida, linux-modules, Stephen Rothwell,
linux-next
In-Reply-To: <49af6d76-bcb7-4343-8903-390040e2c49b@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 8479 bytes --]
Hello Daniel,
[Adding Stephen and linux-next to Cc]
On Sat, Nov 01, 2025 at 10:39:08PM +0100, Daniel Gomez wrote:
> On 24/09/2025 14.39, Andreas Hindborg wrote:
> > Extend the `module!` macro with support module parameters. Also add some
> > string to integer parsing functions.
> >
> > Based on the original module parameter support by Miguel [1],
> > later extended and generalized by Adam for more types [2][3].
> > Originally tracked at [4].
> >
> > Link: https://github.com/Rust-for-Linux/linux/pull/7 [1]
> > Link: https://github.com/Rust-for-Linux/linux/pull/82 [2]
> > Link: https://github.com/Rust-for-Linux/linux/pull/87 [3]
> > Link: https://github.com/Rust-for-Linux/linux/issues/11 [4]
> > Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>
> I tested this series with rust_minimal module. They LGTM,
>
> Tested-by: Daniel Gomez <da.gomez@samsung.com>
>
> The patches did not apply cleanly to v6.18-rc3, at least not when using b4.
> However, when applying them to the base commit and then rebasing onto v6.18-rc3,
> I didn't see any conflicts.
I don't know how you use b4, but
git checkout v6.18-rc3
b4 am -3 49af6d76-bcb7-4343-8903-390040e2c49b@kernel.org
git am -3 ./v18_20250924_a_hindborg_rust_extend_module_macro_with_integer_parameter_support.mbx
works fine on my end. Using `-3` should have the same effect as applying
the series on top of the original base and rebase it.
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git rebase/20250924-module-params-v3-v18-0-bf512c35d910@kernel.org
git range-diff FETCH_HEAD...HEAD
confirms that.
> I've created a temporary branch with this rebase here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/log/?h=rebase/20250924-module-params-v3-v18-0-bf512c35d910@kernel.org
>
> Can you take a look when you can? I'll merge this shortly after checking with
> Uwe, as there are some minor conflicts with his tree.
>
> + Uwe
>
> These are the conflicts I see when merging the patch series from Michal [1]
> (Introduce import_ns support for Rust). I believe these are trivial things that
> we will get notified from linux-next merging. But let me know what you think as
> you have requested in that thread.
>
> [1] Link: https://lore.kernel.org/all/20251028-pwm_fixes-v1-0-25a532d31998@samsung.com/
Yeah, I expect that Stephen will highlight the conflicts, but I prefer
to not be surprised by that and consider linux-next more a fallback
security net that I don't want to use. I like it to be the other way
round and tell Stephen about conflicts to expect :-)
> ...
> Applying: rust: macros: Add support for 'imports_ns' to module!
> Patch failed at 0008 rust: macros: Add support for 'imports_ns' to module!
> error: patch failed: rust/macros/module.rs:98
> error: rust/macros/module.rs: patch does not apply
> hint: Use 'git am --show-current-patch=diff' to see the failed patch
> hint: When you have resolved this problem, run "git am --continue".
> hint: If you prefer to skip this patch, run "git am --skip" instead.
> hint: To restore the original branch and stop patching, run "git am --abort".
> hint: Disable this message with "git config set advice.mergeConflict false"
>
> git am --show-current-patch=diff
That command shows the patch to apply, but not the conflict, let alone
your resolution.
> ---
> rust/macros/module.rs | 8 ++++++++
> 1 file changed, 8 insertions(+)
> ---
> rust/macros/module.rs | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/rust/macros/module.rs b/rust/macros/module.rs
> index 5ee54a00c0b65699596e660b2d4d60e64be2a50c..408cd115487514c8be79724d901c676435696376 100644
> --- a/rust/macros/module.rs
> +++ b/rust/macros/module.rs
> @@ -98,6 +98,7 @@ struct ModuleInfo {
> description: Option<String>,
> alias: Option<Vec<String>>,
> firmware: Option<Vec<String>>,
> + imports_ns: Option<Vec<String>>,
> }
So here the addition of `params` is missing.
> [...]
When I merge your branch mentioned above with my pwm/for-next and
resolve the merge conflicts, the resolution looks as follows. The only
non-trivial thing is that
if let Some(imports) = info.imports_ns {
now needs a & for `info`.
Best regards
Uwe
diff --cc rust/macros/module.rs
index d62e9c1e2a89,408cd1154875..000000000000
--- a/rust/macros/module.rs
+++ b/rust/macros/module.rs
@@@ -205,50 -98,7 +205,51 @@@ struct ModuleInfo
description: Option<String>,
alias: Option<Vec<String>>,
firmware: Option<Vec<String>>,
+ imports_ns: Option<Vec<String>>,
+ params: Option<Vec<Parameter>>,
+}
+
+#[derive(Debug)]
+struct Parameter {
+ name: String,
+ ptype: String,
+ default: String,
+ description: String,
+}
+
+fn expect_params(it: &mut token_stream::IntoIter) -> Vec<Parameter> {
+ let params = expect_group(it);
+ assert_eq!(params.delimiter(), Delimiter::Brace);
+ let mut it = params.stream().into_iter();
+ let mut parsed = Vec::new();
+
+ loop {
+ let param_name = match it.next() {
+ Some(TokenTree::Ident(ident)) => ident.to_string(),
+ Some(_) => panic!("Expected Ident or end"),
+ None => break,
+ };
+
+ assert_eq!(expect_punct(&mut it), ':');
+ let param_type = expect_ident(&mut it);
+ let group = expect_group(&mut it);
+ assert_eq!(group.delimiter(), Delimiter::Brace);
+ assert_eq!(expect_punct(&mut it), ',');
+
+ let mut param_it = group.stream().into_iter();
+ let param_default = expect_param_default(&mut param_it);
+ let param_description = expect_string_field(&mut param_it, "description");
+ expect_end(&mut param_it);
+
+ parsed.push(Parameter {
+ name: param_name,
+ ptype: param_type,
+ default: param_default,
+ description: param_description,
+ })
+ }
+
+ parsed
}
impl ModuleInfo {
@@@ -263,7 -113,7 +264,8 @@@
"license",
"alias",
"firmware",
+ "imports_ns",
+ "params",
];
const REQUIRED_KEYS: &[&str] = &["type", "name", "license"];
let mut seen_keys = Vec::new();
@@@ -289,7 -139,7 +291,8 @@@
"license" => info.license = expect_string_ascii(it),
"alias" => info.alias = Some(expect_string_array(it)),
"firmware" => info.firmware = Some(expect_string_array(it)),
+ "imports_ns" => info.imports_ns = Some(expect_string_array(it)),
+ "params" => info.params = Some(expect_params(it)),
_ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."),
}
@@@ -329,25 -179,30 +332,30 @@@ pub(crate) fn module(ts: TokenStream) -
// Rust does not allow hyphens in identifiers, use underscore instead.
let ident = info.name.replace('-', "_");
let mut modinfo = ModInfoBuilder::new(ident.as_ref());
- if let Some(authors) = info.authors {
+ if let Some(authors) = &info.authors {
for author in authors {
- modinfo.emit("author", &author);
+ modinfo.emit("author", author);
}
}
- if let Some(description) = info.description {
- modinfo.emit("description", &description);
+ if let Some(description) = &info.description {
+ modinfo.emit("description", description);
}
modinfo.emit("license", &info.license);
- if let Some(aliases) = info.alias {
+ if let Some(aliases) = &info.alias {
for alias in aliases {
- modinfo.emit("alias", &alias);
+ modinfo.emit("alias", alias);
}
}
- if let Some(firmware) = info.firmware {
+ if let Some(firmware) = &info.firmware {
for fw in firmware {
- modinfo.emit("firmware", &fw);
+ modinfo.emit("firmware", fw);
}
}
- if let Some(imports) = info.imports_ns {
++ if let Some(imports) = &info.imports_ns {
+ for ns in imports {
+ modinfo.emit("import_ns", &ns);
+ }
+ }
// Built-in modules also export the `file` modinfo string.
let file =
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2] lsm,ima: new LSM hook security_kernel_module_read_file to access decompressed kernel module
From: Mimi Zohar @ 2025-11-02 15:05 UTC (permalink / raw)
To: Paul Moore, Coiby Xu
Cc: linux-integrity, linux-security-module, Karel Srot, James Morris,
Serge E. Hallyn, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
open list, open list:MODULE SUPPORT
In-Reply-To: <CAHC9VhRBXkW+XuqhxJvEOYR_VMxFh4TRWUtXzZky=AG_nyBYEQ@mail.gmail.com>
On Sat, 2025-11-01 at 12:50 -0400, Paul Moore wrote:
> On Fri, Oct 31, 2025 at 3:41 AM Coiby Xu <coxu@redhat.com> wrote:
> >
> > Currently, when in-kernel module decompression (CONFIG_MODULE_DECOMPRESS)
> > is enabled, IMA has no way to verify the appended module signature as it
> > can't decompress the module.
> >
> > Define a new LSM hook security_kernel_module_read_file which will be
> > called after kernel module decompression is done so IMA can access the
> > decompressed kernel module to verify the appended signature.
> >
> > Since IMA can access both xattr and appended kernel module signature
> > with the new LSM hook, it no longer uses the security_kernel_post_read_file
> > LSM hook for kernel module loading.
> >
> > Before enabling in-kernel module decompression, a kernel module in
> > initramfs can still be loaded with ima_policy=secure_boot. So adjust the
> > kernel module rule in secure_boot policy to allow either an IMA
> > signature OR an appended signature i.e. to use
> > "appraise func=MODULE_CHECK appraise_type=imasig|modsig".
> >
> > Reported-by: Karel Srot <ksrot@redhat.com>
> > Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> > Signed-off-by: Coiby Xu <coxu@redhat.com>
> > ---
> > v1: https://lore.kernel.org/linux-integrity/20250928030358.3873311-1-coxu@redhat.com/
> >
> > include/linux/lsm_hook_defs.h | 2 ++
> > include/linux/security.h | 7 +++++++
> > kernel/module/main.c | 10 +++++++++-
> > security/integrity/ima/ima_main.c | 26 ++++++++++++++++++++++++++
> > security/integrity/ima/ima_policy.c | 2 +-
> > security/security.c | 17 +++++++++++++++++
> > 6 files changed, 62 insertions(+), 2 deletions(-)
>
> We don't really need a new LSM hook for this do we? Can't we just
> define a new file read type, e.g. READING_MODULE_DECOMPRESS, and do
> another call to security_kernel_post_read_file() after the module is
> unpacked? Something like the snippet below ...
Yes, this is similar to my suggestion based on defining multiple enumerations:
READING_MODULE, READING_COMPRESSED_MODULE, and READING_DECOMPRESSED_MODULE.
With this solution, IMA would need to make an exception in the post kernel
module read for the READING_COMPRESSED_MODULE case, since the kernel module has
not yet been decompressed.
Coiby suggested further simplification by moving the call later. At which point
either there is or isn't an appended signature for non-compressed and
decompressed kernel modules.
As long as you don't have a problem calling the security_kernel_post_read_file()
hook again, could we move the call later and pass READING_MODULE_UNCOMPRESSED?
>
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index c66b26184936..f127000d2e0a 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -3693,6 +3693,14 @@ static int init_module_from_file(struct file *f, const ch
> ar __user * uargs, int
> mod_stat_add_long(len, &invalid_decompress_bytes);
> return err;
> }
> +
> + err = security_kernel_post_read_file(f,
> + (char *)info.hdr, info.len,
> + READING_MODULE_DECOMPRESS);
> + if (err) {
> + mod_stat_inc(&failed_kreads);
> + return err;
> + }
> } else {
> info.hdr = buf;
> info.len = len;
== defer security_kernel_post_read_file() call to here ==
Mimi
^ permalink raw reply
* Re: [PATCH v2] lsm,ima: new LSM hook security_kernel_module_read_file to access decompressed kernel module
From: Paul Moore @ 2025-11-02 15:43 UTC (permalink / raw)
To: Mimi Zohar
Cc: Coiby Xu, linux-integrity, linux-security-module, Karel Srot,
James Morris, Serge E. Hallyn, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, open list, open list:MODULE SUPPORT
In-Reply-To: <baa39fcd1b6b485f14b8f06dcd96b81359e6e491.camel@linux.ibm.com>
On Sun, Nov 2, 2025 at 10:06 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Sat, 2025-11-01 at 12:50 -0400, Paul Moore wrote:
> > On Fri, Oct 31, 2025 at 3:41 AM Coiby Xu <coxu@redhat.com> wrote:
> > >
> > > Currently, when in-kernel module decompression (CONFIG_MODULE_DECOMPRESS)
> > > is enabled, IMA has no way to verify the appended module signature as it
> > > can't decompress the module.
> > >
> > > Define a new LSM hook security_kernel_module_read_file which will be
> > > called after kernel module decompression is done so IMA can access the
> > > decompressed kernel module to verify the appended signature.
> > >
> > > Since IMA can access both xattr and appended kernel module signature
> > > with the new LSM hook, it no longer uses the security_kernel_post_read_file
> > > LSM hook for kernel module loading.
> > >
> > > Before enabling in-kernel module decompression, a kernel module in
> > > initramfs can still be loaded with ima_policy=secure_boot. So adjust the
> > > kernel module rule in secure_boot policy to allow either an IMA
> > > signature OR an appended signature i.e. to use
> > > "appraise func=MODULE_CHECK appraise_type=imasig|modsig".
> > >
> > > Reported-by: Karel Srot <ksrot@redhat.com>
> > > Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> > > Signed-off-by: Coiby Xu <coxu@redhat.com>
> > > ---
> > > v1: https://lore.kernel.org/linux-integrity/20250928030358.3873311-1-coxu@redhat.com/
> > >
> > > include/linux/lsm_hook_defs.h | 2 ++
> > > include/linux/security.h | 7 +++++++
> > > kernel/module/main.c | 10 +++++++++-
> > > security/integrity/ima/ima_main.c | 26 ++++++++++++++++++++++++++
> > > security/integrity/ima/ima_policy.c | 2 +-
> > > security/security.c | 17 +++++++++++++++++
> > > 6 files changed, 62 insertions(+), 2 deletions(-)
> >
> > We don't really need a new LSM hook for this do we? Can't we just
> > define a new file read type, e.g. READING_MODULE_DECOMPRESS, and do
> > another call to security_kernel_post_read_file() after the module is
> > unpacked? Something like the snippet below ...
>
> Yes, this is similar to my suggestion based on defining multiple enumerations:
> READING_MODULE, READING_COMPRESSED_MODULE, and READING_DECOMPRESSED_MODULE.
> With this solution, IMA would need to make an exception in the post kernel
> module read for the READING_COMPRESSED_MODULE case, since the kernel module has
> not yet been decompressed.
>
> Coiby suggested further simplification by moving the call later. At which point
> either there is or isn't an appended signature for non-compressed and
> decompressed kernel modules.
>
> As long as you don't have a problem calling the security_kernel_post_read_file()
> hook again, could we move the call later and pass READING_MODULE_UNCOMPRESSED?
It isn't clear from these comments if you are talking about moving
only the second security_kernel_post_read_file() call that was
proposed for init_module_from_file() to later in the function, leaving
the call in kernel_read_file() intact, or something else?
I think we want to leave the hook calls in kernel_read_file() intact,
in which case I'm not certain what advantage there is in moving the
security_kernel_post_read_file() call to a location where it is called
in init_module_from_file() regardless of if the module is compressed
or not. In the uncompressed case you are calling the hook twice for
no real benefit? It may be helpful to submit a patch with your
proposal as a patch can be worth a thousand words ;)
> > diff --git a/kernel/module/main.c b/kernel/module/main.c
> > index c66b26184936..f127000d2e0a 100644
> > --- a/kernel/module/main.c
> > +++ b/kernel/module/main.c
> > @@ -3693,6 +3693,14 @@ static int init_module_from_file(struct file *f, const ch
> > ar __user * uargs, int
> > mod_stat_add_long(len, &invalid_decompress_bytes);
> > return err;
> > }
> > +
> > + err = security_kernel_post_read_file(f,
> > + (char *)info.hdr, info.len,
> > + READING_MODULE_DECOMPRESS);
> > + if (err) {
> > + mod_stat_inc(&failed_kreads);
> > + return err;
> > + }
> > } else {
> > info.hdr = buf;
> > info.len = len;
>
> == defer security_kernel_post_read_file() call to here ==
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH 2/2] module: Simplify warning on positive returns from module_init()
From: Aaron Tomlin @ 2025-11-02 18:23 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: linux-modules, linux-kernel, Petr Pavlu
In-Reply-To: <20251013-module-warn-ret-v1-2-ab65b41af01f@intel.com>
On Mon, Oct 13, 2025 at 09:26:24AM -0700, Lucas De Marchi wrote:
> It should now be rare to trigger this warning - it doesn't need to be so
> verbose. Make it follow the usual style in the module loading code.
>
> For the same reason, drop the dump_stack().
>
> Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> ---
> kernel/module/main.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index 74ff87b13c517..31c54bf6df4b2 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -3045,13 +3045,9 @@ static noinline int do_init_module(struct module *mod)
> }
> goto fail_free_freeinit;
> }
> - if (ret > 0) {
> - pr_warn("%s: '%s'->init suspiciously returned %d, it should "
> - "follow 0/-E convention\n"
> - "%s: loading module anyway...\n",
> - __func__, mod->name, ret, __func__);
> - dump_stack();
> - }
> + if (ret > 0)
> + pr_warn("%s: init suspiciously returned %d, it should follow 0/-E convention\n",
> + mod->name, ret);
>
> /* Now it's a first class citizen! */
> mod->state = MODULE_STATE_LIVE;
>
> --
> 2.51.0
>
>
Fair enough. Looks good to me.
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH 1/2] module: Override -EEXISTS module return
From: Aaron Tomlin @ 2025-11-02 18:23 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: linux-modules, linux-kernel, Petr Pavlu
In-Reply-To: <20251013-module-warn-ret-v1-1-ab65b41af01f@intel.com>
On Mon, Oct 13, 2025 at 09:26:23AM -0700, Lucas De Marchi wrote:
> The -EEXIST errno is reserved by the module loading functionality. When
> userspace calls [f]init_module(), it expects a -EEXIST to mean that the
> module is already loaded in the kernel. If module_init() returns it,
> that is not true anymore.
>
> Add a warning and override the return code to workaround modules
> currently returning the wrong code. It's expected that they eventually
> migrate to a better suited error.
>
> Closes: https://lore.kernel.org/all/aKLzsAX14ybEjHfJ@orbyte.nwl.cc/
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> ---
> kernel/module/main.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index c66b261849362..74ff87b13c517 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -3038,6 +3038,11 @@ static noinline int do_init_module(struct module *mod)
> if (mod->init != NULL)
> ret = do_one_initcall(mod->init);
> if (ret < 0) {
> + if (ret == -EEXIST) {
> + pr_warn("%s: init suspiciously returned -EEXIST: Overriding with -EBUSY\n",
> + mod->name);
> + ret = -EBUSY;
> + }
> goto fail_free_freeinit;
> }
> if (ret > 0) {
>
> --
> 2.51.0
>
>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH v18 0/7] rust: extend `module!` macro with integer parameter support
From: Daniel Gomez @ 2025-11-02 21:19 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andreas Hindborg, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Alice Ryhl, Masahiro Yamada,
Nathan Chancellor, Luis Chamberlain, Danilo Krummrich,
Benno Lossin, Nicolas Schier, Michal Wilczynski, Trevor Gross,
Adam Bratschi-Kaye, rust-for-linux, linux-kernel, linux-kbuild,
Petr Pavlu, Sami Tolvanen, Daniel Gomez, Simona Vetter, Greg KH,
Fiona Behrens, Daniel Almeida, linux-modules, Stephen Rothwell,
linux-next
In-Reply-To: <er7h34im2rk627usnvbre3clqvsx3uzev7kboy33pd7oac747c@nvtl7y2mmdde>
On 02/11/2025 10.56, Uwe Kleine-König wrote:
> Hello Daniel,
>
> [Adding Stephen and linux-next to Cc]
>
> On Sat, Nov 01, 2025 at 10:39:08PM +0100, Daniel Gomez wrote:
>> On 24/09/2025 14.39, Andreas Hindborg wrote:
>>> Extend the `module!` macro with support module parameters. Also add some
>>> string to integer parsing functions.
>>>
>>> Based on the original module parameter support by Miguel [1],
>>> later extended and generalized by Adam for more types [2][3].
>>> Originally tracked at [4].
>>>
>>> Link: https://github.com/Rust-for-Linux/linux/pull/7 [1]
>>> Link: https://github.com/Rust-for-Linux/linux/pull/82 [2]
>>> Link: https://github.com/Rust-for-Linux/linux/pull/87 [3]
>>> Link: https://github.com/Rust-for-Linux/linux/issues/11 [4]
>>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>>
>> I tested this series with rust_minimal module. They LGTM,
>>
>> Tested-by: Daniel Gomez <da.gomez@samsung.com>
>>
>> The patches did not apply cleanly to v6.18-rc3, at least not when using b4.
>> However, when applying them to the base commit and then rebasing onto v6.18-rc3,
>> I didn't see any conflicts.
>
> I don't know how you use b4, but
>
> git checkout v6.18-rc3
> b4 am -3 49af6d76-bcb7-4343-8903-390040e2c49b@kernel.org
> git am -3 ./v18_20250924_a_hindborg_rust_extend_module_macro_with_integer_parameter_support.mbx
>
> works fine on my end. Using `-3` should have the same effect as applying
> the series on top of the original base and rebase it.
Right, that's what I did but manually. I didn't know about that argument :).
>
> git fetch https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git rebase/20250924-module-params-v3-v18-0-bf512c35d910@kernel.org
> git range-diff FETCH_HEAD...HEAD
>
> confirms that.
>
>> I've created a temporary branch with this rebase here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/log/?h=rebase/20250924-module-params-v3-v18-0-bf512c35d910@kernel.org
>>
>> Can you take a look when you can? I'll merge this shortly after checking with
>> Uwe, as there are some minor conflicts with his tree.
>>
>> + Uwe
>>
>> These are the conflicts I see when merging the patch series from Michal [1]
>> (Introduce import_ns support for Rust). I believe these are trivial things that
>> we will get notified from linux-next merging. But let me know what you think as
>> you have requested in that thread.
>>
>> [1] Link: https://lore.kernel.org/all/20251028-pwm_fixes-v1-0-25a532d31998@samsung.com/
>
> Yeah, I expect that Stephen will highlight the conflicts, but I prefer
> to not be surprised by that and consider linux-next more a fallback
> security net that I don't want to use. I like it to be the other way
> round and tell Stephen about conflicts to expect :-)
Please Stephen, check the proposed changes below. I plan to merge this series in
modules' tree and it will conflict with Uwe's tree on rust/macros/module.rs file.
>
>> ...
>> Applying: rust: macros: Add support for 'imports_ns' to module!
>> Patch failed at 0008 rust: macros: Add support for 'imports_ns' to module!
>> error: patch failed: rust/macros/module.rs:98
>> error: rust/macros/module.rs: patch does not apply
>> hint: Use 'git am --show-current-patch=diff' to see the failed patch
>> hint: When you have resolved this problem, run "git am --continue".
>> hint: If you prefer to skip this patch, run "git am --skip" instead.
>> hint: To restore the original branch and stop patching, run "git am --abort".
>> hint: Disable this message with "git config set advice.mergeConflict false"
>>
>> git am --show-current-patch=diff
>
> That command shows the patch to apply, but not the conflict, let alone
> your resolution.
>
>> ---
>> rust/macros/module.rs | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>> ---
>> rust/macros/module.rs | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/rust/macros/module.rs b/rust/macros/module.rs
>> index 5ee54a00c0b65699596e660b2d4d60e64be2a50c..408cd115487514c8be79724d901c676435696376 100644
>> --- a/rust/macros/module.rs
>> +++ b/rust/macros/module.rs
>> @@ -98,6 +98,7 @@ struct ModuleInfo {
>> description: Option<String>,
>> alias: Option<Vec<String>>,
>> firmware: Option<Vec<String>>,
>> + imports_ns: Option<Vec<String>>,
>> }
>
> So here the addition of `params` is missing.
>
>> [...]
>
> When I merge your branch mentioned above with my pwm/for-next and
> resolve the merge conflicts, the resolution looks as follows. The only
> non-trivial thing is that
>
> if let Some(imports) = info.imports_ns {
>
> now needs a & for `info`.
Correct.
In case it's necessary, I've merged your changes into the modules's -next
branch and attach the diff for you and Stephen. Not sure which order trees are
taken/merged, though.
>
> Best regards
> Uwe
>
> diff --cc rust/macros/module.rs
> index d62e9c1e2a89,408cd1154875..000000000000
> --- a/rust/macros/module.rs
> +++ b/rust/macros/module.rs
> @@@ -205,50 -98,7 +205,51 @@@ struct ModuleInfo
> description: Option<String>,
> alias: Option<Vec<String>>,
> firmware: Option<Vec<String>>,
> + imports_ns: Option<Vec<String>>,
> + params: Option<Vec<Parameter>>,
> +}
> +
> +#[derive(Debug)]
> +struct Parameter {
> + name: String,
> + ptype: String,
> + default: String,
> + description: String,
> +}
> +
> +fn expect_params(it: &mut token_stream::IntoIter) -> Vec<Parameter> {
> + let params = expect_group(it);
> + assert_eq!(params.delimiter(), Delimiter::Brace);
> + let mut it = params.stream().into_iter();
> + let mut parsed = Vec::new();
> +
> + loop {
> + let param_name = match it.next() {
> + Some(TokenTree::Ident(ident)) => ident.to_string(),
> + Some(_) => panic!("Expected Ident or end"),
> + None => break,
> + };
> +
> + assert_eq!(expect_punct(&mut it), ':');
> + let param_type = expect_ident(&mut it);
> + let group = expect_group(&mut it);
> + assert_eq!(group.delimiter(), Delimiter::Brace);
> + assert_eq!(expect_punct(&mut it), ',');
> +
> + let mut param_it = group.stream().into_iter();
> + let param_default = expect_param_default(&mut param_it);
> + let param_description = expect_string_field(&mut param_it, "description");
> + expect_end(&mut param_it);
> +
> + parsed.push(Parameter {
> + name: param_name,
> + ptype: param_type,
> + default: param_default,
> + description: param_description,
> + })
> + }
> +
> + parsed
> }
>
> impl ModuleInfo {
> @@@ -263,7 -113,7 +264,8 @@@
> "license",
> "alias",
> "firmware",
> + "imports_ns",
> + "params",
> ];
> const REQUIRED_KEYS: &[&str] = &["type", "name", "license"];
> let mut seen_keys = Vec::new();
> @@@ -289,7 -139,7 +291,8 @@@
> "license" => info.license = expect_string_ascii(it),
> "alias" => info.alias = Some(expect_string_array(it)),
> "firmware" => info.firmware = Some(expect_string_array(it)),
> + "imports_ns" => info.imports_ns = Some(expect_string_array(it)),
> + "params" => info.params = Some(expect_params(it)),
> _ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."),
> }
>
> @@@ -329,25 -179,30 +332,30 @@@ pub(crate) fn module(ts: TokenStream) -
> // Rust does not allow hyphens in identifiers, use underscore instead.
> let ident = info.name.replace('-', "_");
> let mut modinfo = ModInfoBuilder::new(ident.as_ref());
> - if let Some(authors) = info.authors {
> + if let Some(authors) = &info.authors {
> for author in authors {
> - modinfo.emit("author", &author);
> + modinfo.emit("author", author);
> }
> }
> - if let Some(description) = info.description {
> - modinfo.emit("description", &description);
> + if let Some(description) = &info.description {
> + modinfo.emit("description", description);
> }
> modinfo.emit("license", &info.license);
> - if let Some(aliases) = info.alias {
> + if let Some(aliases) = &info.alias {
> for alias in aliases {
> - modinfo.emit("alias", &alias);
> + modinfo.emit("alias", alias);
> }
> }
> - if let Some(firmware) = info.firmware {
> + if let Some(firmware) = &info.firmware {
> for fw in firmware {
> - modinfo.emit("firmware", &fw);
> + modinfo.emit("firmware", fw);
> }
> }
> - if let Some(imports) = info.imports_ns {
> ++ if let Some(imports) = &info.imports_ns {
> + for ns in imports {
> + modinfo.emit("import_ns", &ns);
> + }
> + }
>
> // Built-in modules also export the `file` modinfo string.
> let file =
The resolution looks good to me.
As I applied Michal's patch on top of Andreas changes, it looks like this on
my side:
diff --git a/rust/macros/module.rs b/rust/macros/module.rs
index d62e9c1e2a89..5bf0a487de50 100644
--- a/rust/macros/module.rs
+++ b/rust/macros/module.rs
@@ -206,6 +206,7 @@ struct ModuleInfo {
alias: Option<Vec<String>>,
firmware: Option<Vec<String>>,
params: Option<Vec<Parameter>>,
+ imports_ns: Option<Vec<String>>,
}
#[derive(Debug)]
@@ -264,6 +265,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {
"alias",
"firmware",
"params",
+ "imports_ns",
];
const REQUIRED_KEYS: &[&str] = &["type", "name", "license"];
let mut seen_keys = Vec::new();
@@ -290,6 +292,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {
"alias" => info.alias = Some(expect_string_array(it)),
"firmware" => info.firmware = Some(expect_string_array(it)),
"params" => info.params = Some(expect_params(it)),
+ "imports_ns" => info.imports_ns = Some(expect_string_array(it)),
_ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."),
}
@@ -348,6 +351,11 @@ pub(crate) fn module(ts: TokenStream) -> TokenStream {
modinfo.emit("firmware", fw);
}
}
+ if let Some(imports) = &info.imports_ns {
+ for ns in imports {
+ modinfo.emit("import_ns", &ns);
+ }
+ }
// Built-in modules also export the `file` modinfo string.
let file =
^ permalink raw reply related
* Re: [PATCH v8 04/23] slab: add sheaf support for batching kfree_rcu() operations
From: Harry Yoo @ 2025-11-03 3:17 UTC (permalink / raw)
To: Daniel Gomez
Cc: Vlastimil Babka, Suren Baghdasaryan, Liam R. Howlett,
Christoph Lameter, David Rientjes, Roman Gushchin,
Uladzislau Rezki, Sidhartha Kumar, linux-mm, linux-kernel, rcu,
maple-tree, linux-modules, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Aaron Tomlin, Lucas De Marchi
In-Reply-To: <0406562e-2066-4cf8-9902-b2b0616dd742@kernel.org>
On Fri, Oct 31, 2025 at 10:32:54PM +0100, Daniel Gomez wrote:
>
>
> On 10/09/2025 10.01, Vlastimil Babka wrote:
> > Extend the sheaf infrastructure for more efficient kfree_rcu() handling.
> > For caches with sheaves, on each cpu maintain a rcu_free sheaf in
> > addition to main and spare sheaves.
> >
> > kfree_rcu() operations will try to put objects on this sheaf. Once full,
> > the sheaf is detached and submitted to call_rcu() with a handler that
> > will try to put it in the barn, or flush to slab pages using bulk free,
> > when the barn is full. Then a new empty sheaf must be obtained to put
> > more objects there.
> >
> > It's possible that no free sheaves are available to use for a new
> > rcu_free sheaf, and the allocation in kfree_rcu() context can only use
> > GFP_NOWAIT and thus may fail. In that case, fall back to the existing
> > kfree_rcu() implementation.
> >
> > Expected advantages:
> > - batching the kfree_rcu() operations, that could eventually replace the
> > existing batching
> > - sheaves can be reused for allocations via barn instead of being
> > flushed to slabs, which is more efficient
> > - this includes cases where only some cpus are allowed to process rcu
> > callbacks (Android)
> >
> > Possible disadvantage:
> > - objects might be waiting for more than their grace period (it is
> > determined by the last object freed into the sheaf), increasing memory
> > usage - but the existing batching does that too.
> >
> > Only implement this for CONFIG_KVFREE_RCU_BATCHED as the tiny
> > implementation favors smaller memory footprint over performance.
> >
> > Also for now skip the usage of rcu sheaf for CONFIG_PREEMPT_RT as the
> > contexts where kfree_rcu() is called might not be compatible with taking
> > a barn spinlock or a GFP_NOWAIT allocation of a new sheaf taking a
> > spinlock - the current kfree_rcu() implementation avoids doing that.
> >
> > Teach kvfree_rcu_barrier() to flush all rcu_free sheaves from all caches
> > that have them. This is not a cheap operation, but the barrier usage is
> > rare - currently kmem_cache_destroy() or on module unload.
> >
> > Add CONFIG_SLUB_STATS counters free_rcu_sheaf and free_rcu_sheaf_fail to
> > count how many kfree_rcu() used the rcu_free sheaf successfully and how
> > many had to fall back to the existing implementation.
> >
> > Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>
> Hi Vlastimil,
>
> This patch increases kmod selftest (stress module loader) runtime by about
> ~50-60%, from ~200s to ~300s total execution time. My tested kernel has
> CONFIG_KVFREE_RCU_BATCHED enabled. Any idea or suggestions on what might be
> causing this, or how to address it?
This is likely due to increased kvfree_rcu_barrier() during module unload.
It currently iterates over all CPUs x slab caches (that enabled sheaves,
there should be only a few now) pair to make sure rcu sheaf is flushed
by the time kvfree_rcu_barrier() returns.
Just being curious, do you have any serious workload that depends on
the performance of module unload?
--
Cheers,
Harry / Hyeonggon
^ permalink raw reply
* Re: [PATCH v2 3/3] module: Add compile-time check for embedded NUL characters
From: Hans Verkuil @ 2025-11-03 8:54 UTC (permalink / raw)
To: Kees Cook, Luis Chamberlain
Cc: Rusty Russell, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
linux-modules, Malcolm Priestley, Mauro Carvalho Chehab,
Hans Verkuil, Uwe Kleine-König, linux-kernel, linux-media,
linux-hardening
In-Reply-To: <20251010030610.3032147-3-kees@kernel.org>
On 10/10/2025 05:06, Kees Cook wrote:
> Long ago, the kernel module license checks were bypassed by embedding a
> NUL character in the MODULE_LICENSE() string[1]. By using a string like
> "GPL\0proprietary text", the kernel would only read "GPL" due to C string
> termination at the NUL byte, allowing proprietary modules to avoid kernel
> tainting and access GPL-only symbols.
>
> The MODULE_INFO() macro stores these strings in the .modinfo ELF
> section, and get_next_modinfo() uses strcmp()-family functions
> which stop at the first NUL. This split the embedded string into two
> separate .modinfo entries, with only the first part being processed by
> license_is_gpl_compatible().
>
> Add a compile-time check using static_assert that compares the full
> string length (sizeof - 1) against __builtin_strlen(), which stops at
> the first NUL. If they differ, compilation fails with a clear error
> message.
>
> While this check can still be circumvented by modifying the ELF binary
> post-compilation, it prevents accidental embedded NULs and forces
> intentional abuse to require deliberate binary manipulation rather than
> simple source-level tricks.
>
> Build tested with test modules containing both valid and invalid license
> strings. The check correctly rejects:
>
> MODULE_LICENSE("GPL\0proprietary")
>
> while accepting normal declarations:
>
> MODULE_LICENSE("GPL")
Who will take this series? I can take the first two media patches and
someone else can take this last patch, or I can take all, or someone
else can take all patches. The media patches already have my 'Reviewed-by'.
Any preferences?
Regards,
Hans
>
> Link: https://lwn.net/Articles/82305/ [1]
> Suggested-by: Rusty Russell <rusty@rustcorp.com.au>
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
> Cc: Luis Chamberlain <mcgrof@kernel.org>
> Cc: Petr Pavlu <petr.pavlu@suse.com>
> Cc: Daniel Gomez <da.gomez@kernel.org>
> Cc: Sami Tolvanen <samitolvanen@google.com>
> Cc: <linux-modules@vger.kernel.org>
> ---
> include/linux/moduleparam.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> index 6907aedc4f74..915f32f7d888 100644
> --- a/include/linux/moduleparam.h
> +++ b/include/linux/moduleparam.h
> @@ -26,6 +26,9 @@
>
> /* Generic info of form tag = "info" */
> #define MODULE_INFO(tag, info) \
> + static_assert( \
> + sizeof(info) - 1 == __builtin_strlen(info), \
> + "MODULE_INFO(" #tag ", ...) contains embedded NUL byte"); \
> static const char __UNIQUE_ID(modinfo)[] \
> __used __section(".modinfo") __aligned(1) \
> = __MODULE_INFO_PREFIX __stringify(tag) "=" info
^ permalink raw reply
* Re: [PATCH v2 3/3] module: Add compile-time check for embedded NUL characters
From: Daniel Gomez @ 2025-11-03 8:58 UTC (permalink / raw)
To: Hans Verkuil, Kees Cook, Luis Chamberlain
Cc: Rusty Russell, Petr Pavlu, Sami Tolvanen, linux-modules,
Malcolm Priestley, Mauro Carvalho Chehab, Hans Verkuil,
Uwe Kleine-König, linux-kernel, linux-media, linux-hardening
In-Reply-To: <91866583-037f-4607-b148-4ddf38ffaf51@kernel.org>
On 03/11/2025 09.54, Hans Verkuil wrote:
> On 10/10/2025 05:06, Kees Cook wrote:
>> Long ago, the kernel module license checks were bypassed by embedding a
>> NUL character in the MODULE_LICENSE() string[1]. By using a string like
>> "GPL\0proprietary text", the kernel would only read "GPL" due to C string
>> termination at the NUL byte, allowing proprietary modules to avoid kernel
>> tainting and access GPL-only symbols.
>>
>> The MODULE_INFO() macro stores these strings in the .modinfo ELF
>> section, and get_next_modinfo() uses strcmp()-family functions
>> which stop at the first NUL. This split the embedded string into two
>> separate .modinfo entries, with only the first part being processed by
>> license_is_gpl_compatible().
>>
>> Add a compile-time check using static_assert that compares the full
>> string length (sizeof - 1) against __builtin_strlen(), which stops at
>> the first NUL. If they differ, compilation fails with a clear error
>> message.
>>
>> While this check can still be circumvented by modifying the ELF binary
>> post-compilation, it prevents accidental embedded NULs and forces
>> intentional abuse to require deliberate binary manipulation rather than
>> simple source-level tricks.
>>
>> Build tested with test modules containing both valid and invalid license
>> strings. The check correctly rejects:
>>
>> MODULE_LICENSE("GPL\0proprietary")
>>
>> while accepting normal declarations:
>>
>> MODULE_LICENSE("GPL")
>
> Who will take this series? I can take the first two media patches and
> someone else can take this last patch, or I can take all, or someone
> else can take all patches. The media patches already have my 'Reviewed-by'.
>
> Any preferences?
I will take patch 3 in modules' tree.
>
> Regards,
>
> Hans
>
>>
>> Link: https://lwn.net/Articles/82305/ [1]
>> Suggested-by: Rusty Russell <rusty@rustcorp.com.au>
>> Signed-off-by: Kees Cook <kees@kernel.org>
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
^ permalink raw reply
* Re: [PATCH v2 3/3] module: Add compile-time check for embedded NUL characters
From: Hans Verkuil @ 2025-11-03 9:05 UTC (permalink / raw)
To: Daniel Gomez, Kees Cook, Luis Chamberlain
Cc: Rusty Russell, Petr Pavlu, Sami Tolvanen, linux-modules,
Malcolm Priestley, Mauro Carvalho Chehab, Hans Verkuil,
Uwe Kleine-König, linux-kernel, linux-media, linux-hardening
In-Reply-To: <1c3e9bc8-0d25-46b2-98a3-643157f78b21@kernel.org>
On 03/11/2025 09:58, Daniel Gomez wrote:
> On 03/11/2025 09.54, Hans Verkuil wrote:
>> On 10/10/2025 05:06, Kees Cook wrote:
>>> Long ago, the kernel module license checks were bypassed by embedding a
>>> NUL character in the MODULE_LICENSE() string[1]. By using a string like
>>> "GPL\0proprietary text", the kernel would only read "GPL" due to C string
>>> termination at the NUL byte, allowing proprietary modules to avoid kernel
>>> tainting and access GPL-only symbols.
>>>
>>> The MODULE_INFO() macro stores these strings in the .modinfo ELF
>>> section, and get_next_modinfo() uses strcmp()-family functions
>>> which stop at the first NUL. This split the embedded string into two
>>> separate .modinfo entries, with only the first part being processed by
>>> license_is_gpl_compatible().
>>>
>>> Add a compile-time check using static_assert that compares the full
>>> string length (sizeof - 1) against __builtin_strlen(), which stops at
>>> the first NUL. If they differ, compilation fails with a clear error
>>> message.
>>>
>>> While this check can still be circumvented by modifying the ELF binary
>>> post-compilation, it prevents accidental embedded NULs and forces
>>> intentional abuse to require deliberate binary manipulation rather than
>>> simple source-level tricks.
>>>
>>> Build tested with test modules containing both valid and invalid license
>>> strings. The check correctly rejects:
>>>
>>> MODULE_LICENSE("GPL\0proprietary")
>>>
>>> while accepting normal declarations:
>>>
>>> MODULE_LICENSE("GPL")
>>
>> Who will take this series? I can take the first two media patches and
>> someone else can take this last patch, or I can take all, or someone
>> else can take all patches. The media patches already have my 'Reviewed-by'.
>>
>> Any preferences?
>
> I will take patch 3 in modules' tree.
OK, then I'll take patches 1 and 2 in the media tree.
Regards,
Hans
>
>
>>
>> Regards,
>>
>> Hans
>>
>>>
>>> Link: https://lwn.net/Articles/82305/ [1]
>>> Suggested-by: Rusty Russell <rusty@rustcorp.com.au>
>>> Signed-off-by: Kees Cook <kees@kernel.org>
>
> Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
^ permalink raw reply
* Re: [PATCH] docs: ABI: sysfs-module: update modules taint flags
From: Petr Pavlu @ 2025-11-03 9:19 UTC (permalink / raw)
To: Randy Dunlap
Cc: Jonathan Corbet, linux-doc, Greg Kroah-Hartman, Luis Chamberlain,
Daniel Gomez, Sami Tolvanen, linux-modules, linux-kernel
In-Reply-To: <20251102060458.517911-1-rdunlap@infradead.org>
On 11/2/25 7:04 AM, Randy Dunlap wrote:
> Add missing taint flags for loadable modules, as pointed out by
> Petr Pavlu [1].
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> [1] https://lore.kernel.org/all/c58152f1-0fbe-4f50-bb61-e2f4c0584025@suse.com/
> ---
Looks ok to me. I would only move the "[1]" line before the
"Signed-off-by" tag in the commit message and separate them by an empty
line. Some tooling might rely on the tags being separately at the end.
I guess this can be directly adjusted by a maintainer that picks up the
patch and there is no need to resend it.
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
--
Thanks,
Petr
> Cc: Petr Pavlu <petr.pavlu@suse.com>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Luis Chamberlain <mcgrof@kernel.org>
> Cc: Daniel Gomez <da.gomez@kernel.org>
> Cc: Sami Tolvanen <samitolvanen@google.com>
> Cc: linux-modules@vger.kernel.org
> ---
> Documentation/ABI/testing/sysfs-module | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- linux-next-20251031.orig/Documentation/ABI/testing/sysfs-module
> +++ linux-next-20251031/Documentation/ABI/testing/sysfs-module
> @@ -59,6 +59,8 @@ Description: Module taint flags:
> F force-loaded module
> C staging driver module
> E unsigned module
> + K livepatch module
> + N in-kernel test module
> == =====================
>
> What: /sys/module/grant_table/parameters/free_per_iteration
^ permalink raw reply
* Re: [PATCH v3 22/28] x86: Use RCU in all users of __module_address().
From: Michal Pecio @ 2025-11-03 10:08 UTC (permalink / raw)
To: bigeasy
Cc: bp, da.gomez, dave.hansen, hpa, jpoimboe, linux-kernel,
linux-modules, mcgrof, mingo, paulmck, peterz, petr.pavlu,
samitolvanen, tglx, x86
In-Reply-To: <20250108090457.512198-23-bigeasy@linutronix.de>
> x86: Use RCU in all users of __module_address().
>
> __module_address() can be invoked within a RCU section, there is no
> requirement to have preemption disabled.
>
> Replace the preempt_disable() section around __module_address() with
> RCU.
>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Josh Poimboeuf <jpoimboe@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: x86@kernel.org
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> arch/x86/kernel/callthunks.c | 3 +--
> arch/x86/kernel/unwind_orc.c | 4 +---
> 2 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kernel/callthunks.c b/arch/x86/kernel/callthunks.c
> index f17d166078823..276b5368ff6b0 100644
> --- a/arch/x86/kernel/callthunks.c
> +++ b/arch/x86/kernel/callthunks.c
> @@ -98,11 +98,10 @@ static inline bool within_module_coretext(void *addr)
> #ifdef CONFIG_MODULES
> struct module *mod;
>
> - preempt_disable();
> + guard(rcu)();
> mod = __module_address((unsigned long)addr);
> if (mod && within_module_core((unsigned long)addr, mod))
> ret = true;
> - preempt_enable();
> #endif
> return ret;
> }
> diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
> index d4705a348a804..977ee75e047c8 100644
> --- a/arch/x86/kernel/unwind_orc.c
> +++ b/arch/x86/kernel/unwind_orc.c
> @@ -476,7 +476,7 @@ bool unwind_next_frame(struct unwind_state *state)
> return false;
>
> /* Don't let modules unload while we're reading their ORC data. */
> - preempt_disable();
> + guard(rcu)();
>
> /* End-of-stack check for user tasks: */
> if (state->regs && user_mode(state->regs))
> @@ -669,14 +669,12 @@ bool unwind_next_frame(struct unwind_state *state)
> goto err;
> }
>
> - preempt_enable();
> return true;
Hi,
There is a regression report on a distribution forum which involves
an out of tree module on a patched kernel (yes, I know) calling
stack_trace_save() in task context, which arrives here and apparently
calls the various deref_stack_xxx() functions with preemption enabled,
which in turn call stack_access_ok() leading to a BUG:
Nov 02 21:44:30 ArchBasement kernel: BUG: using smp_processor_id() in preemptible [00000000] code: Xorg/1183
Nov 02 21:44:30 ArchBasement kernel: caller is in_entry_stack+0x11/0x60
Nov 02 21:44:30 ArchBasement kernel: CPU: 0 UID: 1000 PID: 1183 Comm: Xorg Tainted: P OE 6.16.12-hardened1-1-hardened #1 PREEMPT(full) 6edb90a7a07fab33bbee72d6d5ef53ba6eec3b9c
Nov 02 21:44:30 ArchBasement kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Nov 02 21:44:30 ArchBasement kernel: Hardware name: ASUS All Series/Z97-E, BIOS 0803 02/23/2016
Nov 02 21:44:30 ArchBasement kernel: Call Trace:
Nov 02 21:44:30 ArchBasement kernel: <TASK>
Nov 02 21:44:30 ArchBasement kernel: dump_stack_lvl+0x5d/0x80
Nov 02 21:44:30 ArchBasement kernel: check_preemption_disabled+0xe5/0xf0
Nov 02 21:44:30 ArchBasement kernel: in_entry_stack+0x11/0x60
Nov 02 21:44:30 ArchBasement kernel: get_stack_info+0x2c/0x80
Nov 02 21:44:30 ArchBasement kernel: stack_access_ok+0x51/0xa0
Nov 02 21:44:30 ArchBasement kernel: unwind_next_frame+0x1cb/0x7b0
Nov 02 21:44:30 ArchBasement kernel: ? _nv003168kms+0x42/0x50 [nvidia_modeset 90775ea8a26c5e58b97ef4b3f46eb45efa040eb2]
Nov 02 21:44:30 ArchBasement kernel: ? __pfx_stack_trace_consume_entry+0x10/0x10
Nov 02 21:44:30 ArchBasement kernel: arch_stack_walk+0xa6/0x110
Nov 02 21:44:30 ArchBasement kernel: ? _nv003168kms+0x42/0x50 [nvidia_modeset 90775ea8a26c5e58b97ef4b3f46eb45efa040eb2]
Nov 02 21:44:30 ArchBasement kernel: stack_trace_save+0x4d/0x70
Is this nvidia doing something wrong, or a problem with this commit?
The removed code suggests that preemption is allowed here, and as far
as I see, this call trace is still possible on vanilla 6.18. Perhaps
preempt_disable() needs to be restored around this code?
Regards,
Michal
^ permalink raw reply
* Re: [PATCH v3 22/28] x86: Use RCU in all users of __module_address().
From: Sebastian Andrzej Siewior @ 2025-11-03 10:34 UTC (permalink / raw)
To: Michal Pecio
Cc: bp, da.gomez, dave.hansen, hpa, jpoimboe, linux-kernel,
linux-modules, mcgrof, mingo, paulmck, peterz, petr.pavlu,
samitolvanen, tglx, x86
In-Reply-To: <20251103110835.1dca378c.michal.pecio@gmail.com>
On 2025-11-03 11:08:35 [+0100], Michal Pecio wrote:
> Hi,
Hi,
> There is a regression report on a distribution forum which involves
> an out of tree module on a patched kernel (yes, I know) calling
> stack_trace_save() in task context, which arrives here and apparently
> calls the various deref_stack_xxx() functions with preemption enabled,
> which in turn call stack_access_ok() leading to a BUG:
>
> Nov 02 21:44:30 ArchBasement kernel: BUG: using smp_processor_id() in preemptible [00000000] code: Xorg/1183
> Nov 02 21:44:30 ArchBasement kernel: caller is in_entry_stack+0x11/0x60
> Nov 02 21:44:30 ArchBasement kernel: CPU: 0 UID: 1000 PID: 1183 Comm: Xorg Tainted: P OE 6.16.12-hardened1-1-hardened #1 PREEMPT(full) 6edb90a7a07fab33bbee72d6d5ef53ba6eec3b9c
> Nov 02 21:44:30 ArchBasement kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
> Nov 02 21:44:30 ArchBasement kernel: Hardware name: ASUS All Series/Z97-E, BIOS 0803 02/23/2016
> Nov 02 21:44:30 ArchBasement kernel: Call Trace:
> Nov 02 21:44:30 ArchBasement kernel: <TASK>
> Nov 02 21:44:30 ArchBasement kernel: dump_stack_lvl+0x5d/0x80
> Nov 02 21:44:30 ArchBasement kernel: check_preemption_disabled+0xe5/0xf0
> Nov 02 21:44:30 ArchBasement kernel: in_entry_stack+0x11/0x60
> Nov 02 21:44:30 ArchBasement kernel: get_stack_info+0x2c/0x80
> Nov 02 21:44:30 ArchBasement kernel: stack_access_ok+0x51/0xa0
> Nov 02 21:44:30 ArchBasement kernel: unwind_next_frame+0x1cb/0x7b0
> Nov 02 21:44:30 ArchBasement kernel: ? _nv003168kms+0x42/0x50 [nvidia_modeset 90775ea8a26c5e58b97ef4b3f46eb45efa040eb2]
> Nov 02 21:44:30 ArchBasement kernel: ? __pfx_stack_trace_consume_entry+0x10/0x10
> Nov 02 21:44:30 ArchBasement kernel: arch_stack_walk+0xa6/0x110
> Nov 02 21:44:30 ArchBasement kernel: ? _nv003168kms+0x42/0x50 [nvidia_modeset 90775ea8a26c5e58b97ef4b3f46eb45efa040eb2]
> Nov 02 21:44:30 ArchBasement kernel: stack_trace_save+0x4d/0x70
>
> Is this nvidia doing something wrong, or a problem with this commit?
>
> The removed code suggests that preemption is allowed here, and as far
> as I see, this call trace is still possible on vanilla 6.18. Perhaps
> preempt_disable() needs to be restored around this code?
Do you have the complete backtrace? Is this SMP or UP build?
> Regards,
> Michal
Sebastian
^ permalink raw reply
* Re: [PATCH v3 22/28] x86: Use RCU in all users of __module_address().
From: Michal Pecio @ 2025-11-03 10:39 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: bp, da.gomez, dave.hansen, hpa, jpoimboe, linux-kernel,
linux-modules, mcgrof, mingo, paulmck, peterz, petr.pavlu,
samitolvanen, tglx, x86
In-Reply-To: <20251103103434.D6m23Iud@linutronix.de>
On Mon, 3 Nov 2025 11:34:34 +0100, Sebastian Andrzej Siewior wrote:
> On 2025-11-03 11:08:35 [+0100], Michal Pecio wrote:
> > Hi,
> Hi,
>
> > There is a regression report on a distribution forum which involves
> > an out of tree module on a patched kernel (yes, I know) calling
> > stack_trace_save() in task context, which arrives here and apparently
> > calls the various deref_stack_xxx() functions with preemption enabled,
> > which in turn call stack_access_ok() leading to a BUG:
> >
> > Nov 02 21:44:30 ArchBasement kernel: BUG: using smp_processor_id() in preemptible [00000000] code: Xorg/1183
> > Nov 02 21:44:30 ArchBasement kernel: caller is in_entry_stack+0x11/0x60
> > Nov 02 21:44:30 ArchBasement kernel: CPU: 0 UID: 1000 PID: 1183 Comm: Xorg Tainted: P OE 6.16.12-hardened1-1-hardened #1 PREEMPT(full) 6edb90a7a07fab33bbee72d6d5ef53ba6eec3b9c
> > Nov 02 21:44:30 ArchBasement kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
> > Nov 02 21:44:30 ArchBasement kernel: Hardware name: ASUS All Series/Z97-E, BIOS 0803 02/23/2016
> > Nov 02 21:44:30 ArchBasement kernel: Call Trace:
> > Nov 02 21:44:30 ArchBasement kernel: <TASK>
> > Nov 02 21:44:30 ArchBasement kernel: dump_stack_lvl+0x5d/0x80
> > Nov 02 21:44:30 ArchBasement kernel: check_preemption_disabled+0xe5/0xf0
> > Nov 02 21:44:30 ArchBasement kernel: in_entry_stack+0x11/0x60
> > Nov 02 21:44:30 ArchBasement kernel: get_stack_info+0x2c/0x80
> > Nov 02 21:44:30 ArchBasement kernel: stack_access_ok+0x51/0xa0
> > Nov 02 21:44:30 ArchBasement kernel: unwind_next_frame+0x1cb/0x7b0
> > Nov 02 21:44:30 ArchBasement kernel: ? _nv003168kms+0x42/0x50 [nvidia_modeset 90775ea8a26c5e58b97ef4b3f46eb45efa040eb2]
> > Nov 02 21:44:30 ArchBasement kernel: ? __pfx_stack_trace_consume_entry+0x10/0x10
> > Nov 02 21:44:30 ArchBasement kernel: arch_stack_walk+0xa6/0x110
> > Nov 02 21:44:30 ArchBasement kernel: ? _nv003168kms+0x42/0x50 [nvidia_modeset 90775ea8a26c5e58b97ef4b3f46eb45efa040eb2]
> > Nov 02 21:44:30 ArchBasement kernel: stack_trace_save+0x4d/0x70
> >
> > Is this nvidia doing something wrong, or a problem with this commit?
> >
> > The removed code suggests that preemption is allowed here, and as far
> > as I see, this call trace is still possible on vanilla 6.18. Perhaps
> > preempt_disable() needs to be restored around this code?
>
> Do you have the complete backtrace? Is this SMP or UP build?
Sorry, I forgot to include the link. There is also a similar warning
regarding __this_cpu_read(). Pretty sure the kernel is SMP.
https://bbs.archlinux.org/viewtopic.php?id=309960
^ permalink raw reply
* Re: [PATCH v3 22/28] x86: Use RCU in all users of __module_address().
From: Sebastian Andrzej Siewior @ 2025-11-03 11:37 UTC (permalink / raw)
To: Michal Pecio
Cc: bp, da.gomez, dave.hansen, hpa, jpoimboe, linux-kernel,
linux-modules, mcgrof, mingo, paulmck, peterz, petr.pavlu,
samitolvanen, tglx, x86
In-Reply-To: <20251103113907.4e647f33.michal.pecio@gmail.com>
On 2025-11-03 11:39:07 [+0100], Michal Pecio wrote:
> Sorry, I forgot to include the link. There is also a similar warning
> regarding __this_cpu_read(). Pretty sure the kernel is SMP.
>
> https://bbs.archlinux.org/viewtopic.php?id=309960
The stack trace is a bit odd. The compressed version is:
| BUG: using smp_processor_id() in preemptible [00000000] code: Xorg/1183
| caller is in_entry_stack+0x11/0x60
| CPU: 3 UID: 1000 PID: 1183 Comm: Xorg Tainted: P OE 6.16.12-hardened1-1-hardened #1 PREEMPT(full) 6edb90a7a07fab33bbee72d6d5ef53ba6eec3b9c
| Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
| Hardware name: ASUS All Series/Z97-E, BIOS 0803 02/23/2016
| Call Trace:
| <TASK>
| dump_stack_lvl+0x5d/0x80
| check_preemption_disabled+0xe5/0xf0
| in_entry_stack+0x11/0x60
| get_stack_info+0x2c/0x80
| stack_access_ok+0x51/0xa0
| unwind_next_frame+0x1cb/0x7b0
| arch_stack_walk+0xa6/0x110
| stack_trace_save+0x4d/0x70
| __kfence_alloc+0xb7/0x6f0
| __kmalloc_noprof+0x520/0x560
| os_alloc_mem+0x108/0x120 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
| _nv015295rm+0x34/0x50 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
| _nv015297rm+0x2b/0xd0 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
| _nv016352rm+0x1c/0x90 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
| _nv059298rm+0x65/0xb0 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
| _nv054041rm+0x20f/0x360 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
| _nv056165rm+0x54/0xd0 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
| _nv056096rm+0xa0/0x500 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
| _nv015919rm+0x424/0x680 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
| _nv054015rm+0x69/0xd0 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
| _nv014185rm+0x86/0xa0 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
| _nv000652rm+0x5e/0x70 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
| rm_kernel_rmapi_op+0x167/0x273 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
| nvkms_call_rm+0x4c/0x80 [nvidia_modeset 90775ea8a26c5e58b97ef4b3f46eb45efa040eb2]
| _nv003168kms+0x42/0x50 [nvidia_modeset 90775ea8a26c5e58b97ef4b3f46eb45efa040eb2]
| ? do_syscall_64+0x82/0x8d0
| ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
| </TASK>
The last two entries start with a '?' which means it did not originate
from the "stack unwind" but was laying around while passing through.
I would expect the last two entries to be there without the '?' because
userland (as in X here) enters the kernel via a proper syscall entry
which should be part of the stack strace.
Now, get_stack_info() where the warning originates: It starts with a
check to see if the stack pointer belongs to the current task's stack
frame which it does not. Then it checks if the task found is the
currently running task. That it does. So in that case, we must be
serving an exception (such as an IRQ) because the stack does not belong
to the current task. However preemption is not disabled which indicates
that we do not do this.
This in turn suggests that nvidia replaced the stack from while entering
the syscall probably in _nv003168kms() or the binary blob which invokes
the kernel function does not have a proper ORC entry which leads to a
wrong turn in the process.
So the warning is well deserved.
Sebastian
^ permalink raw reply
* Re: [PATCH v18 0/7] rust: extend `module!` macro with integer parameter support
From: Daniel Gomez @ 2025-11-03 14:47 UTC (permalink / raw)
To: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Alice Ryhl, Masahiro Yamada,
Nathan Chancellor, Luis Chamberlain, Danilo Krummrich,
Benno Lossin, Benno Lossin, Nicolas Schier, Andreas Hindborg
Cc: Trevor Gross, Adam Bratschi-Kaye, rust-for-linux, linux-kernel,
linux-kbuild, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Simona Vetter, Greg KH, Fiona Behrens, Daniel Almeida,
linux-modules
In-Reply-To: <20250924-module-params-v3-v18-0-bf512c35d910@kernel.org>
On Wed, 24 Sep 2025 14:39:23 +0200, Andreas Hindborg wrote:
> Extend the `module!` macro with support module parameters. Also add some
> string to integer parsing functions.
>
> Based on the original module parameter support by Miguel [1],
> later extended and generalized by Adam for more types [2][3].
> Originally tracked at [4].
>
> [...]
Applied, thanks!
[1/7] rust: sync: add `SetOnce`
commit: 821fe7bf16c57d690f4f92997f4e51abb93e0347
[2/7] rust: str: add radix prefixed integer parsing functions
commit: 51d9ee90ea9060be240830eb28f5f117ad00318c
[3/7] rust: introduce module_param module
commit: 0b08fc292842a13aa496413b48c1efb83573b8c6
[4/7] rust: module: use a reference in macros::module::module
commit: 3809d7a89fe550bf4065c04adff6dac610daddad
[5/7] rust: module: update the module macro with module parameter support
commit: 0b24f9740f26ac7ad91ac0f4de27717c14de91bd
[6/7] rust: samples: add a module parameter to the rust_minimal sample
commit: e119c2fe8c78632188f6cdeae620951a7032855a
[7/7] modules: add rust modules files to MAINTAINERS
commit: ee3b8134b2bae848e03e56c090ceca4ae76cee06
Best regards,
--
Daniel Gomez <da.gomez@kernel.org>
^ permalink raw reply
* [PATCH v3 0/8] scalable symbol flags with __kflagstab
From: Siddharth Nayyar @ 2025-11-03 16:19 UTC (permalink / raw)
To: petr.pavlu, corbet
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
This patch series implements a mechanism for scalable exported symbol
flags using a separate section called __kflagstab. The series introduces
__kflagstab support, removes *_gpl sections in favor of a GPL flag,
simplifies symbol resolution during module loading.
This series previously added symbol import protection which aims to
restrict the use of "protected symbol" exported by vmlinux, as a use
case for which __kflagstab is being introduced. Such symbols are only
allowed to be imported by signed modules when symbol protection is
enabled. This functionality requires more thought and discussion [1],
and therefore I will create a separate patch series for it. In the
meantime, this series now only focuses on introduction of __kflagstab
which right is an improvement to the module loader's code health [2].
Thank you Petr Pavlu and Jonathan Corbet for their valuable feedback.
---
Changes from v2:
- removed symbol import protection to spin off into its own series
v2:
https://lore.kernel.org/20251013153918.2206045-1-sidnayyar@google.com/
Changes from v1:
- added a check to ensure __kflagstab is present
- added warnings for the obsolete *_gpl sections
- moved protected symbol check before ref_module() call
- moved protected symbol check failure warning to issue detection point
v1:
https://lore.kernel.org/20250829105418.3053274-1-sidnayyar@google.com/
[1] https://lore.kernel.org/cac5ed5e-3320-4db0-99d8-ea5e97e56bfb@suse.com/
[2] https://lore.kernel.org/2bf54830-ea9c-4962-a7ef-653fbed8f8c0@suse.com/
Siddharth Nayyar (8):
define kernel symbol flags
linker: add kflagstab section to vmlinux and modules
modpost: create entries for kflagstab
module loader: use kflagstab instead of *_gpl sections
modpost: put all exported symbols in ksymtab section
module loader: remove references of *_gpl sections
linker: remove *_gpl sections from vmlinux and modules
remove references to *_gpl sections in documentation
Documentation/kbuild/modules.rst | 11 ++--
include/asm-generic/vmlinux.lds.h | 21 ++----
include/linux/export-internal.h | 28 +++++---
include/linux/module.h | 4 +-
include/linux/module_symbol.h | 5 ++
kernel/module/internal.h | 4 +-
kernel/module/main.c | 102 ++++++++++++++----------------
scripts/mod/modpost.c | 16 +++--
scripts/module.lds.S | 3 +-
9 files changed, 99 insertions(+), 95 deletions(-)
--
2.51.1.930.gacf6e81ea2-goog
^ permalink raw reply
* [PATCH v3 1/8] define kernel symbol flags
From: Siddharth Nayyar @ 2025-11-03 16:19 UTC (permalink / raw)
To: petr.pavlu, corbet
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251103161954.1351784-1-sidnayyar@google.com>
Symbol flags is an enumeration used to represent flags as a bitset, for
example a flag to tell if a symbols GPL only.
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
---
include/linux/module_symbol.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/module_symbol.h b/include/linux/module_symbol.h
index 77c9895b9ddb..574609aced99 100644
--- a/include/linux/module_symbol.h
+++ b/include/linux/module_symbol.h
@@ -2,6 +2,11 @@
#ifndef _LINUX_MODULE_SYMBOL_H
#define _LINUX_MODULE_SYMBOL_H
+/* Kernel symbol flags bitset. */
+enum ksym_flags {
+ KSYM_FLAG_GPL_ONLY = 1 << 0,
+};
+
/* This ignores the intensely annoying "mapping symbols" found in ELF files. */
static inline bool is_mapping_symbol(const char *str)
{
--
2.51.1.930.gacf6e81ea2-goog
^ permalink raw reply related
* [PATCH v3 2/8] linker: add kflagstab section to vmlinux and modules
From: Siddharth Nayyar @ 2025-11-03 16:19 UTC (permalink / raw)
To: petr.pavlu, corbet
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251103161954.1351784-1-sidnayyar@google.com>
This section will contain read-only kernel symbol flag values in the
form of a 8-bit bitset.
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
---
include/asm-generic/vmlinux.lds.h | 7 +++++++
scripts/module.lds.S | 1 +
2 files changed, 8 insertions(+)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index ae2d2359b79e..310e2de56211 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -518,6 +518,13 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
__stop___kcrctab_gpl = .; \
} \
\
+ /* Kernel symbol flags table */ \
+ __kflagstab : AT(ADDR(__kflagstab) - LOAD_OFFSET) { \
+ __start___kflagstab = .; \
+ KEEP(*(SORT(___kflagstab+*))) \
+ __stop___kflagstab = .; \
+ } \
+ \
/* Kernel symbol table: strings */ \
__ksymtab_strings : AT(ADDR(__ksymtab_strings) - LOAD_OFFSET) { \
*(__ksymtab_strings) \
diff --git a/scripts/module.lds.S b/scripts/module.lds.S
index ee79c41059f3..9a8a3b6d1569 100644
--- a/scripts/module.lds.S
+++ b/scripts/module.lds.S
@@ -23,6 +23,7 @@ SECTIONS {
__ksymtab_gpl 0 : ALIGN(8) { *(SORT(___ksymtab_gpl+*)) }
__kcrctab 0 : ALIGN(4) { *(SORT(___kcrctab+*)) }
__kcrctab_gpl 0 : ALIGN(4) { *(SORT(___kcrctab_gpl+*)) }
+ __kflagstab 0 : ALIGN(1) { *(SORT(___kflagstab+*)) }
.ctors 0 : ALIGN(8) { *(SORT(.ctors.*)) *(.ctors) }
.init_array 0 : ALIGN(8) { *(SORT(.init_array.*)) *(.init_array) }
--
2.51.1.930.gacf6e81ea2-goog
^ permalink raw reply related
* [PATCH v3 3/8] modpost: create entries for kflagstab
From: Siddharth Nayyar @ 2025-11-03 16:19 UTC (permalink / raw)
To: petr.pavlu, corbet
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251103161954.1351784-1-sidnayyar@google.com>
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
---
include/linux/export-internal.h | 7 +++++++
scripts/mod/modpost.c | 8 ++++++++
2 files changed, 15 insertions(+)
diff --git a/include/linux/export-internal.h b/include/linux/export-internal.h
index d445705ac13c..4123c7592404 100644
--- a/include/linux/export-internal.h
+++ b/include/linux/export-internal.h
@@ -69,4 +69,11 @@
".long " #crc "\n" \
".previous" "\n")
+#define SYMBOL_FLAGS(sym, flags) \
+ asm(" .section \"___kflagstab+" #sym "\",\"a\"" "\n" \
+ "__flags_" #sym ":" "\n" \
+ " .byte " #flags "\n" \
+ " .previous" "\n" \
+ )
+
#endif /* __LINUX_EXPORT_INTERNAL_H__ */
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 5ca7c268294e..f5ce7aeed52d 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -244,6 +244,11 @@ static struct symbol *alloc_symbol(const char *name)
return s;
}
+static uint8_t get_symbol_flags(const struct symbol *sym)
+{
+ return sym->is_gpl_only ? KSYM_FLAG_GPL_ONLY : 0;
+}
+
/* For the hash of exported symbols */
static void hash_add_symbol(struct symbol *sym)
{
@@ -1865,6 +1870,9 @@ static void add_exported_symbols(struct buffer *buf, struct module *mod)
buf_printf(buf, "KSYMTAB_%s(%s, \"%s\", \"%s\");\n",
sym->is_func ? "FUNC" : "DATA", sym->name,
sym->is_gpl_only ? "_gpl" : "", sym->namespace);
+
+ buf_printf(buf, "SYMBOL_FLAGS(%s, 0x%02x);\n",
+ sym->name, get_symbol_flags(sym));
}
if (!modversions)
--
2.51.1.930.gacf6e81ea2-goog
^ permalink raw reply related
* [PATCH v3 4/8] module loader: use kflagstab instead of *_gpl sections
From: Siddharth Nayyar @ 2025-11-03 16:19 UTC (permalink / raw)
To: petr.pavlu, corbet
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251103161954.1351784-1-sidnayyar@google.com>
Read __kflagstab section for vmlinux and modules to determine whether
kernel symbols are GPL only.
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
---
include/linux/module.h | 1 +
kernel/module/internal.h | 1 +
kernel/module/main.c | 55 +++++++++++++++++++++-------------------
3 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 3319a5269d28..9ba6ce433ac3 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -415,6 +415,7 @@ struct module {
/* Exported symbols */
const struct kernel_symbol *syms;
const u32 *crcs;
+ const u8 *flagstab;
unsigned int num_syms;
#ifdef CONFIG_ARCH_USES_CFI_TRAPS
diff --git a/kernel/module/internal.h b/kernel/module/internal.h
index 618202578b42..69b84510e097 100644
--- a/kernel/module/internal.h
+++ b/kernel/module/internal.h
@@ -57,6 +57,7 @@ extern const struct kernel_symbol __start___ksymtab_gpl[];
extern const struct kernel_symbol __stop___ksymtab_gpl[];
extern const u32 __start___kcrctab[];
extern const u32 __start___kcrctab_gpl[];
+extern const u8 __start___kflagstab[];
#define KMOD_PATH_LEN 256
extern char modprobe_path[];
diff --git a/kernel/module/main.c b/kernel/module/main.c
index c66b26184936..4197af526087 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -11,6 +11,7 @@
#include <linux/extable.h>
#include <linux/moduleloader.h>
#include <linux/module_signature.h>
+#include <linux/module_symbol.h>
#include <linux/trace_events.h>
#include <linux/init.h>
#include <linux/kallsyms.h>
@@ -87,7 +88,7 @@ struct mod_tree_root mod_tree __cacheline_aligned = {
struct symsearch {
const struct kernel_symbol *start, *stop;
const u32 *crcs;
- enum mod_license license;
+ const u8 *flagstab;
};
/*
@@ -364,19 +365,21 @@ static bool find_exported_symbol_in_section(const struct symsearch *syms,
struct find_symbol_arg *fsa)
{
struct kernel_symbol *sym;
-
- if (!fsa->gplok && syms->license == GPL_ONLY)
- return false;
+ u8 sym_flags;
sym = bsearch(fsa->name, syms->start, syms->stop - syms->start,
sizeof(struct kernel_symbol), cmp_name);
if (!sym)
return false;
+ sym_flags = *(syms->flagstab + (sym - syms->start));
+ if (!fsa->gplok && (sym_flags & KSYM_FLAG_GPL_ONLY))
+ return false;
+
fsa->owner = owner;
fsa->crc = symversion(syms->crcs, sym - syms->start);
fsa->sym = sym;
- fsa->license = syms->license;
+ fsa->license = (sym_flags & KSYM_FLAG_GPL_ONLY) ? GPL_ONLY : NOT_GPL_ONLY;
return true;
}
@@ -387,36 +390,31 @@ static bool find_exported_symbol_in_section(const struct symsearch *syms,
*/
bool find_symbol(struct find_symbol_arg *fsa)
{
- static const struct symsearch arr[] = {
- { __start___ksymtab, __stop___ksymtab, __start___kcrctab,
- NOT_GPL_ONLY },
- { __start___ksymtab_gpl, __stop___ksymtab_gpl,
- __start___kcrctab_gpl,
- GPL_ONLY },
+ const struct symsearch syms = {
+ .start = __start___ksymtab,
+ .stop = __stop___ksymtab,
+ .crcs = __start___kcrctab,
+ .flagstab = __start___kflagstab,
};
struct module *mod;
- unsigned int i;
- for (i = 0; i < ARRAY_SIZE(arr); i++)
- if (find_exported_symbol_in_section(&arr[i], NULL, fsa))
- return true;
+ if (find_exported_symbol_in_section(&syms, NULL, fsa))
+ return true;
list_for_each_entry_rcu(mod, &modules, list,
lockdep_is_held(&module_mutex)) {
- struct symsearch arr[] = {
- { mod->syms, mod->syms + mod->num_syms, mod->crcs,
- NOT_GPL_ONLY },
- { mod->gpl_syms, mod->gpl_syms + mod->num_gpl_syms,
- mod->gpl_crcs,
- GPL_ONLY },
+ const struct symsearch syms = {
+ .start = mod->syms,
+ .stop = mod->syms + mod->num_syms,
+ .crcs = mod->crcs,
+ .flagstab = mod->flagstab,
};
if (mod->state == MODULE_STATE_UNFORMED)
continue;
- for (i = 0; i < ARRAY_SIZE(arr); i++)
- if (find_exported_symbol_in_section(&arr[i], mod, fsa))
- return true;
+ if (find_exported_symbol_in_section(&syms, mod, fsa))
+ return true;
}
pr_debug("Failed to find symbol %s\n", fsa->name);
@@ -2607,6 +2605,7 @@ static int find_module_sections(struct module *mod, struct load_info *info)
sizeof(*mod->gpl_syms),
&mod->num_gpl_syms);
mod->gpl_crcs = section_addr(info, "__kcrctab_gpl");
+ mod->flagstab = section_addr(info, "__kflagstab");
#ifdef CONFIG_CONSTRUCTORS
mod->ctors = section_objs(info, ".ctors",
@@ -2810,8 +2809,12 @@ static int move_module(struct module *mod, struct load_info *info)
return ret;
}
-static int check_export_symbol_versions(struct module *mod)
+static int check_export_symbol_sections(struct module *mod)
{
+ if (mod->num_syms && !mod->flagstab) {
+ pr_err("%s: no flags for exported symbols\n", mod->name);
+ return -ENOEXEC;
+ }
#ifdef CONFIG_MODVERSIONS
if ((mod->num_syms && !mod->crcs) ||
(mod->num_gpl_syms && !mod->gpl_crcs)) {
@@ -3427,7 +3430,7 @@ static int load_module(struct load_info *info, const char __user *uargs,
if (err)
goto free_unload;
- err = check_export_symbol_versions(mod);
+ err = check_export_symbol_sections(mod);
if (err)
goto free_unload;
--
2.51.1.930.gacf6e81ea2-goog
^ permalink raw reply related
* [PATCH v3 5/8] modpost: put all exported symbols in ksymtab section
From: Siddharth Nayyar @ 2025-11-03 16:19 UTC (permalink / raw)
To: petr.pavlu, corbet
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251103161954.1351784-1-sidnayyar@google.com>
Since the modules loader determines whether an exported symbol is GPL
only from the kflagstab section data, modpost can put all symbols in the
regular ksymtab and stop using the *_gpl versions of the ksymtab and
kcrctab.
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
---
include/linux/export-internal.h | 21 +++++++++++----------
scripts/mod/modpost.c | 8 ++++----
2 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/include/linux/export-internal.h b/include/linux/export-internal.h
index 4123c7592404..726054614752 100644
--- a/include/linux/export-internal.h
+++ b/include/linux/export-internal.h
@@ -37,14 +37,14 @@
* section flag requires it. Use '%progbits' instead of '@progbits' since the
* former apparently works on all arches according to the binutils source.
*/
-#define __KSYMTAB(name, sym, sec, ns) \
+#define __KSYMTAB(name, sym, ns) \
asm(" .section \"__ksymtab_strings\",\"aMS\",%progbits,1" "\n" \
"__kstrtab_" #name ":" "\n" \
" .asciz \"" #name "\"" "\n" \
"__kstrtabns_" #name ":" "\n" \
" .asciz \"" ns "\"" "\n" \
" .previous" "\n" \
- " .section \"___ksymtab" sec "+" #name "\", \"a\"" "\n" \
+ " .section \"___ksymtab+" #name "\", \"a\"" "\n" \
__KSYM_ALIGN "\n" \
"__ksymtab_" #name ":" "\n" \
__KSYM_REF(sym) "\n" \
@@ -59,15 +59,16 @@
#define KSYM_FUNC(name) name
#endif
-#define KSYMTAB_FUNC(name, sec, ns) __KSYMTAB(name, KSYM_FUNC(name), sec, ns)
-#define KSYMTAB_DATA(name, sec, ns) __KSYMTAB(name, name, sec, ns)
+#define KSYMTAB_FUNC(name, ns) __KSYMTAB(name, KSYM_FUNC(name), ns)
+#define KSYMTAB_DATA(name, ns) __KSYMTAB(name, name, ns)
-#define SYMBOL_CRC(sym, crc, sec) \
- asm(".section \"___kcrctab" sec "+" #sym "\",\"a\"" "\n" \
- ".balign 4" "\n" \
- "__crc_" #sym ":" "\n" \
- ".long " #crc "\n" \
- ".previous" "\n")
+#define SYMBOL_CRC(sym, crc) \
+ asm(" .section \"___kcrctab+" #sym "\",\"a\"" "\n" \
+ " .balign 4" "\n" \
+ "__crc_" #sym ":" "\n" \
+ " .long " #crc "\n" \
+ " .previous" "\n" \
+ )
#define SYMBOL_FLAGS(sym, flags) \
asm(" .section \"___kflagstab+" #sym "\",\"a\"" "\n" \
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index f5ce7aeed52d..8936db84779b 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1867,9 +1867,9 @@ static void add_exported_symbols(struct buffer *buf, struct module *mod)
if (trim_unused_exports && !sym->used)
continue;
- buf_printf(buf, "KSYMTAB_%s(%s, \"%s\", \"%s\");\n",
+ buf_printf(buf, "KSYMTAB_%s(%s, \"%s\");\n",
sym->is_func ? "FUNC" : "DATA", sym->name,
- sym->is_gpl_only ? "_gpl" : "", sym->namespace);
+ sym->namespace);
buf_printf(buf, "SYMBOL_FLAGS(%s, 0x%02x);\n",
sym->name, get_symbol_flags(sym));
@@ -1890,8 +1890,8 @@ static void add_exported_symbols(struct buffer *buf, struct module *mod)
sym->name, mod->name, mod->is_vmlinux ? "" : ".ko",
sym->name);
- buf_printf(buf, "SYMBOL_CRC(%s, 0x%08x, \"%s\");\n",
- sym->name, sym->crc, sym->is_gpl_only ? "_gpl" : "");
+ buf_printf(buf, "SYMBOL_CRC(%s, 0x%08x);\n",
+ sym->name, sym->crc);
}
}
--
2.51.1.930.gacf6e81ea2-goog
^ permalink raw reply related
* [PATCH v3 6/8] module loader: remove references of *_gpl sections
From: Siddharth Nayyar @ 2025-11-03 16:19 UTC (permalink / raw)
To: petr.pavlu, corbet
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251103161954.1351784-1-sidnayyar@google.com>
The *_gpl section are not being used populated by modpost anymore. Hence
the module loader doesn't need to find and process these sections in
modules.
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
---
include/linux/module.h | 3 ---
kernel/module/internal.h | 3 ---
kernel/module/main.c | 47 ++++++++++++++++------------------------
3 files changed, 19 insertions(+), 34 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 9ba6ce433ac3..1a9c41318e22 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -431,9 +431,6 @@ struct module {
unsigned int num_kp;
/* GPL-only exported symbols. */
- unsigned int num_gpl_syms;
- const struct kernel_symbol *gpl_syms;
- const u32 *gpl_crcs;
bool using_gplonly_symbols;
#ifdef CONFIG_MODULE_SIG
diff --git a/kernel/module/internal.h b/kernel/module/internal.h
index 69b84510e097..061161cc79d9 100644
--- a/kernel/module/internal.h
+++ b/kernel/module/internal.h
@@ -53,10 +53,7 @@ extern const size_t modinfo_attrs_count;
/* Provided by the linker */
extern const struct kernel_symbol __start___ksymtab[];
extern const struct kernel_symbol __stop___ksymtab[];
-extern const struct kernel_symbol __start___ksymtab_gpl[];
-extern const struct kernel_symbol __stop___ksymtab_gpl[];
extern const u32 __start___kcrctab[];
-extern const u32 __start___kcrctab_gpl[];
extern const u8 __start___kflagstab[];
#define KMOD_PATH_LEN 256
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 4197af526087..f5f9872dc070 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -1464,29 +1464,18 @@ EXPORT_SYMBOL_GPL(__symbol_get);
*/
static int verify_exported_symbols(struct module *mod)
{
- unsigned int i;
const struct kernel_symbol *s;
- struct {
- const struct kernel_symbol *sym;
- unsigned int num;
- } arr[] = {
- { mod->syms, mod->num_syms },
- { mod->gpl_syms, mod->num_gpl_syms },
- };
-
- for (i = 0; i < ARRAY_SIZE(arr); i++) {
- for (s = arr[i].sym; s < arr[i].sym + arr[i].num; s++) {
- struct find_symbol_arg fsa = {
- .name = kernel_symbol_name(s),
- .gplok = true,
- };
- if (find_symbol(&fsa)) {
- pr_err("%s: exports duplicate symbol %s"
- " (owned by %s)\n",
- mod->name, kernel_symbol_name(s),
- module_name(fsa.owner));
- return -ENOEXEC;
- }
+ for (s = mod->syms; s < mod->syms + mod->num_syms; s++) {
+ struct find_symbol_arg fsa = {
+ .name = kernel_symbol_name(s),
+ .gplok = true,
+ };
+ if (find_symbol(&fsa)) {
+ pr_err("%s: exports duplicate symbol %s"
+ " (owned by %s)\n",
+ mod->name, kernel_symbol_name(s),
+ module_name(fsa.owner));
+ return -ENOEXEC;
}
}
return 0;
@@ -2601,12 +2590,15 @@ static int find_module_sections(struct module *mod, struct load_info *info)
mod->syms = section_objs(info, "__ksymtab",
sizeof(*mod->syms), &mod->num_syms);
mod->crcs = section_addr(info, "__kcrctab");
- mod->gpl_syms = section_objs(info, "__ksymtab_gpl",
- sizeof(*mod->gpl_syms),
- &mod->num_gpl_syms);
- mod->gpl_crcs = section_addr(info, "__kcrctab_gpl");
mod->flagstab = section_addr(info, "__kflagstab");
+ if (section_addr(info, "__ksymtab_gpl"))
+ pr_warn("%s: ignoring obsolete section __ksymtab_gpl\n",
+ mod->name);
+ if (section_addr(info, "__kcrctab_gpl"))
+ pr_warn("%s: ignoring obsolete section __kcrctab_gpl\n",
+ mod->name);
+
#ifdef CONFIG_CONSTRUCTORS
mod->ctors = section_objs(info, ".ctors",
sizeof(*mod->ctors), &mod->num_ctors);
@@ -2816,8 +2808,7 @@ static int check_export_symbol_sections(struct module *mod)
return -ENOEXEC;
}
#ifdef CONFIG_MODVERSIONS
- if ((mod->num_syms && !mod->crcs) ||
- (mod->num_gpl_syms && !mod->gpl_crcs)) {
+ if (mod->num_syms && !mod->crcs) {
return try_to_force_load(mod,
"no versions for exported symbols");
}
--
2.51.1.930.gacf6e81ea2-goog
^ permalink raw reply related
* [PATCH v3 7/8] linker: remove *_gpl sections from vmlinux and modules
From: Siddharth Nayyar @ 2025-11-03 16:19 UTC (permalink / raw)
To: petr.pavlu, corbet
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251103161954.1351784-1-sidnayyar@google.com>
These sections are not used anymore and can be removed from vmlinux and
modules.
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
---
include/asm-generic/vmlinux.lds.h | 18 ++----------------
scripts/module.lds.S | 2 --
2 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 310e2de56211..6490b93d23b1 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -490,34 +490,20 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
\
PRINTK_INDEX \
\
- /* Kernel symbol table: Normal symbols */ \
+ /* Kernel symbol table */ \
__ksymtab : AT(ADDR(__ksymtab) - LOAD_OFFSET) { \
__start___ksymtab = .; \
KEEP(*(SORT(___ksymtab+*))) \
__stop___ksymtab = .; \
} \
\
- /* Kernel symbol table: GPL-only symbols */ \
- __ksymtab_gpl : AT(ADDR(__ksymtab_gpl) - LOAD_OFFSET) { \
- __start___ksymtab_gpl = .; \
- KEEP(*(SORT(___ksymtab_gpl+*))) \
- __stop___ksymtab_gpl = .; \
- } \
- \
- /* Kernel symbol table: Normal symbols */ \
+ /* Kernel symbol CRC table */ \
__kcrctab : AT(ADDR(__kcrctab) - LOAD_OFFSET) { \
__start___kcrctab = .; \
KEEP(*(SORT(___kcrctab+*))) \
__stop___kcrctab = .; \
} \
\
- /* Kernel symbol table: GPL-only symbols */ \
- __kcrctab_gpl : AT(ADDR(__kcrctab_gpl) - LOAD_OFFSET) { \
- __start___kcrctab_gpl = .; \
- KEEP(*(SORT(___kcrctab_gpl+*))) \
- __stop___kcrctab_gpl = .; \
- } \
- \
/* Kernel symbol flags table */ \
__kflagstab : AT(ADDR(__kflagstab) - LOAD_OFFSET) { \
__start___kflagstab = .; \
diff --git a/scripts/module.lds.S b/scripts/module.lds.S
index 9a8a3b6d1569..1841a43d8771 100644
--- a/scripts/module.lds.S
+++ b/scripts/module.lds.S
@@ -20,9 +20,7 @@ SECTIONS {
}
__ksymtab 0 : ALIGN(8) { *(SORT(___ksymtab+*)) }
- __ksymtab_gpl 0 : ALIGN(8) { *(SORT(___ksymtab_gpl+*)) }
__kcrctab 0 : ALIGN(4) { *(SORT(___kcrctab+*)) }
- __kcrctab_gpl 0 : ALIGN(4) { *(SORT(___kcrctab_gpl+*)) }
__kflagstab 0 : ALIGN(1) { *(SORT(___kflagstab+*)) }
.ctors 0 : ALIGN(8) { *(SORT(.ctors.*)) *(.ctors) }
--
2.51.1.930.gacf6e81ea2-goog
^ permalink raw reply related
* [PATCH v3 8/8] remove references to *_gpl sections in documentation
From: Siddharth Nayyar @ 2025-11-03 16:19 UTC (permalink / raw)
To: petr.pavlu, corbet
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251103161954.1351784-1-sidnayyar@google.com>
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
---
Documentation/kbuild/modules.rst | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/kbuild/modules.rst b/Documentation/kbuild/modules.rst
index d0703605bfa4..b3a26a36ee17 100644
--- a/Documentation/kbuild/modules.rst
+++ b/Documentation/kbuild/modules.rst
@@ -426,11 +426,12 @@ Symbols From the Kernel (vmlinux + modules)
Version Information Formats
---------------------------
- Exported symbols have information stored in __ksymtab or __ksymtab_gpl
- sections. Symbol names and namespaces are stored in __ksymtab_strings,
- using a format similar to the string table used for ELF. If
- CONFIG_MODVERSIONS is enabled, the CRCs corresponding to exported
- symbols will be added to the __kcrctab or __kcrctab_gpl.
+ Exported symbols have information stored in the __ksymtab and
+ __kflagstab sections. Symbol names and namespaces are stored in
+ __ksymtab_strings section, using a format similar to the string
+ table used for ELF. If CONFIG_MODVERSIONS is enabled, the CRCs
+ corresponding to exported symbols will be added to the
+ __kcrctab section.
If CONFIG_BASIC_MODVERSIONS is enabled (default with
CONFIG_MODVERSIONS), imported symbols will have their symbol name and
--
2.51.1.930.gacf6e81ea2-goog
^ permalink raw reply related
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