* Re: [PATCH v3 8/8] x86/ftrace: enable EXECMEM_ROX_CACHE for ftrace allocations
From: Mike Rapoport @ 2025-08-21 6:11 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrew Morton, Andy Lutomirski, Borislav Petkov, Christophe Leroy,
Daniel Gomez, Dave Hansen, Ingo Molnar, Liam R. Howlett,
Luis Chamberlain, Mark Rutland, Masami Hiramatsu, H. Peter Anvin,
Peter Zijlstra, Petr Pavlu, Sami Tolvanen, Thomas Gleixner,
Yann Ylavic, linux-kernel, linux-mm, linux-modules,
linux-trace-kernel, x86
In-Reply-To: <20250820184743.0302a8b5@gandalf.local.home>
On Wed, Aug 20, 2025 at 06:47:43PM -0400, Steven Rostedt wrote:
> On Sun, 13 Jul 2025 10:17:30 +0300
> Mike Rapoport <rppt@kernel.org> wrote:
>
> > From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> >
> > For the most part ftrace uses text poking and can handle ROX memory.
> > The only place that requires writable memory is create_trampoline() that
> > updates the allocated memory and in the end makes it ROX.
> >
> > Use execmem_alloc_rw() in x86::ftrace::alloc_tramp() and enable ROX cache
> > for EXECMEM_FTRACE when configuration and CPU features allow that.
> >
> > Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > ---
>
> The "ftrace=function" kernel command line started crashing with v6.17-rc1,
> and I bisected it down to this commit:
>
> 5d79c2be5081 ("x86/ftrace: enable EXECMEM_ROX_CACHE for ftrace allocations")
>
> On boot I hit this:
>
> [ 0.159269] BUG: kernel NULL pointer dereference, address: 000000000000001c
> [ 0.160254] #PF: supervisor read access in kernel mode
> [ 0.160975] #PF: error_code(0x0000) - not-present page
> [ 0.161697] PGD 0 P4D 0
> [ 0.162055] Oops: Oops: 0000 [#1] SMP PTI
> [ 0.162619] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.17.0-rc2-test-00006-g48d06e78b7cb-dirty #9 PREEMPT(undef)
> [ 0.164141] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> [ 0.165439] RIP: 0010:kmem_cache_alloc_noprof (mm/slub.c:4237)
> [ 0.177483] Call Trace:
> [ 0.177828] <TASK>
> [ 0.178123] mas_alloc_nodes (lib/maple_tree.c:176 (discriminator 2) lib/maple_tree.c:1255 (discriminator 2))
> [ 0.178692] mas_store_gfp (lib/maple_tree.c:5468)
> [ 0.179223] execmem_cache_add_locked (mm/execmem.c:207)
> [ 0.179870] execmem_alloc (mm/execmem.c:213 mm/execmem.c:313 mm/execmem.c:335 mm/execmem.c:475)
> [ 0.180397] ? ftrace_caller (arch/x86/kernel/ftrace_64.S:169)
> [ 0.180922] ? __pfx_ftrace_caller (arch/x86/kernel/ftrace_64.S:158)
> [ 0.181517] execmem_alloc_rw (mm/execmem.c:487)
> [ 0.182052] arch_ftrace_update_trampoline (arch/x86/kernel/ftrace.c:266 arch/x86/kernel/ftrace.c:344 arch/x86/kernel/ftrace.c:474)
> [ 0.182778] ? ftrace_caller_op_ptr (arch/x86/kernel/ftrace_64.S:182)
> [ 0.183388] ftrace_update_trampoline (kernel/trace/ftrace.c:7947)
> [ 0.184024] __register_ftrace_function (kernel/trace/ftrace.c:368)
> [ 0.184682] ftrace_startup (kernel/trace/ftrace.c:3048)
> [ 0.185205] ? __pfx_function_trace_call (kernel/trace/trace_functions.c:210)
> [ 0.185877] register_ftrace_function_nolock (kernel/trace/ftrace.c:8717)
> [ 0.186595] register_ftrace_function (kernel/trace/ftrace.c:8745)
> [ 0.187254] ? __pfx_function_trace_call (kernel/trace/trace_functions.c:210)
> [ 0.187924] function_trace_init (kernel/trace/trace_functions.c:170)
> [ 0.188499] tracing_set_tracer (kernel/trace/trace.c:5916 kernel/trace/trace.c:6349)
> [ 0.189088] register_tracer (kernel/trace/trace.c:2391)
> [ 0.189642] early_trace_init (kernel/trace/trace.c:11075 kernel/trace/trace.c:11149)
> [ 0.190204] start_kernel (init/main.c:970)
> [ 0.190732] x86_64_start_reservations (arch/x86/kernel/head64.c:307)
> [ 0.191381] x86_64_start_kernel (??:?)
> [ 0.191955] common_startup_64 (arch/x86/kernel/head_64.S:419)
> [ 0.192534] </TASK>
> [ 0.192839] Modules linked in:
> [ 0.193267] CR2: 000000000000001c
> [ 0.193730] ---[ end trace 0000000000000000 ]---
maple tree is initialized after ftrace, so the patch below should fix it:
diff --git a/init/main.c b/init/main.c
index 0ee0ee7b7c2c..5753e9539ae6 100644
--- a/init/main.c
+++ b/init/main.c
@@ -956,6 +956,7 @@ void start_kernel(void)
sort_main_extable();
trap_init();
mm_core_init();
+ maple_tree_init();
poking_init();
ftrace_init();
@@ -973,7 +974,6 @@ void start_kernel(void)
"Interrupts were enabled *very* early, fixing it\n"))
local_irq_disable();
radix_tree_init();
- maple_tree_init();
/*
* Set up housekeeping before setting up workqueues to allow the unbound
> -- Steve
--
Sincerely yours,
Mike.
^ permalink raw reply related
* Re: [PATCH v3 8/8] x86/ftrace: enable EXECMEM_ROX_CACHE for ftrace allocations
From: Steven Rostedt @ 2025-08-20 22:47 UTC (permalink / raw)
To: Mike Rapoport
Cc: Andrew Morton, Andy Lutomirski, Borislav Petkov, Christophe Leroy,
Daniel Gomez, Dave Hansen, Ingo Molnar, Liam R. Howlett,
Luis Chamberlain, Mark Rutland, Masami Hiramatsu, H. Peter Anvin,
Peter Zijlstra, Petr Pavlu, Sami Tolvanen, Thomas Gleixner,
Yann Ylavic, linux-kernel, linux-mm, linux-modules,
linux-trace-kernel, x86
In-Reply-To: <20250713071730.4117334-9-rppt@kernel.org>
On Sun, 13 Jul 2025 10:17:30 +0300
Mike Rapoport <rppt@kernel.org> wrote:
> From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
>
> For the most part ftrace uses text poking and can handle ROX memory.
> The only place that requires writable memory is create_trampoline() that
> updates the allocated memory and in the end makes it ROX.
>
> Use execmem_alloc_rw() in x86::ftrace::alloc_tramp() and enable ROX cache
> for EXECMEM_FTRACE when configuration and CPU features allow that.
>
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
The "ftrace=function" kernel command line started crashing with v6.17-rc1,
and I bisected it down to this commit:
5d79c2be5081 ("x86/ftrace: enable EXECMEM_ROX_CACHE for ftrace allocations")
On boot I hit this:
[ 0.159269] BUG: kernel NULL pointer dereference, address: 000000000000001c
[ 0.160254] #PF: supervisor read access in kernel mode
[ 0.160975] #PF: error_code(0x0000) - not-present page
[ 0.161697] PGD 0 P4D 0
[ 0.162055] Oops: Oops: 0000 [#1] SMP PTI
[ 0.162619] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.17.0-rc2-test-00006-g48d06e78b7cb-dirty #9 PREEMPT(undef)
[ 0.164141] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 0.165439] RIP: 0010:kmem_cache_alloc_noprof (mm/slub.c:4237)
[ 0.166186] Code: 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 fc 53 48 83 e4 f0 48 83 ec 20 8b 05 c9 b6 7e 01 <44> 8b 77 1c 65 4c 8b 2d b5 ea 20 02 4c 89 6c 24 18 41 89 f5 21 f0
All code
========
0: 90 nop
1: 90 nop
2: 90 nop
3: f3 0f 1e fa endbr64
7: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
c: 55 push %rbp
d: 48 89 e5 mov %rsp,%rbp
10: 41 57 push %r15
12: 41 56 push %r14
14: 41 55 push %r13
16: 41 54 push %r12
18: 49 89 fc mov %rdi,%r12
1b: 53 push %rbx
1c: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp
20: 48 83 ec 20 sub $0x20,%rsp
24: 8b 05 c9 b6 7e 01 mov 0x17eb6c9(%rip),%eax # 0x17eb6f3
2a:* 44 8b 77 1c mov 0x1c(%rdi),%r14d <-- trapping instruction
2e: 65 4c 8b 2d b5 ea 20 mov %gs:0x220eab5(%rip),%r13 # 0x220eaeb
35: 02
36: 4c 89 6c 24 18 mov %r13,0x18(%rsp)
3b: 41 89 f5 mov %esi,%r13d
3e: 21 f0 and %esi,%eax
Code starting with the faulting instruction
===========================================
0: 44 8b 77 1c mov 0x1c(%rdi),%r14d
4: 65 4c 8b 2d b5 ea 20 mov %gs:0x220eab5(%rip),%r13 # 0x220eac1
b: 02
c: 4c 89 6c 24 18 mov %r13,0x18(%rsp)
11: 41 89 f5 mov %esi,%r13d
14: 21 f0 and %esi,%eax
[ 0.168811] RSP: 0000:ffffffffb2e03b30 EFLAGS: 00010086
[ 0.169545] RAX: 0000000001fff33f RBX: 0000000000000000 RCX: 0000000000000000
[ 0.170544] RDX: 0000000000002800 RSI: 0000000000002800 RDI: 0000000000000000
[ 0.171554] RBP: ffffffffb2e03b80 R08: 0000000000000004 R09: ffffffffb2e03c90
[ 0.172549] R10: ffffffffb2e03c90 R11: 0000000000000000 R12: 0000000000000000
[ 0.173544] R13: ffffffffb2e03c90 R14: ffffffffb2e03c90 R15: 0000000000000001
[ 0.174542] FS: 0000000000000000(0000) GS:ffff9d2808114000(0000) knlGS:0000000000000000
[ 0.175684] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.176486] CR2: 000000000000001c CR3: 000000007264c001 CR4: 00000000000200b0
[ 0.177483] Call Trace:
[ 0.177828] <TASK>
[ 0.178123] mas_alloc_nodes (lib/maple_tree.c:176 (discriminator 2) lib/maple_tree.c:1255 (discriminator 2))
[ 0.178692] mas_store_gfp (lib/maple_tree.c:5468)
[ 0.179223] execmem_cache_add_locked (mm/execmem.c:207)
[ 0.179870] execmem_alloc (mm/execmem.c:213 mm/execmem.c:313 mm/execmem.c:335 mm/execmem.c:475)
[ 0.180397] ? ftrace_caller (arch/x86/kernel/ftrace_64.S:169)
[ 0.180922] ? __pfx_ftrace_caller (arch/x86/kernel/ftrace_64.S:158)
[ 0.181517] execmem_alloc_rw (mm/execmem.c:487)
[ 0.182052] arch_ftrace_update_trampoline (arch/x86/kernel/ftrace.c:266 arch/x86/kernel/ftrace.c:344 arch/x86/kernel/ftrace.c:474)
[ 0.182778] ? ftrace_caller_op_ptr (arch/x86/kernel/ftrace_64.S:182)
[ 0.183388] ftrace_update_trampoline (kernel/trace/ftrace.c:7947)
[ 0.184024] __register_ftrace_function (kernel/trace/ftrace.c:368)
[ 0.184682] ftrace_startup (kernel/trace/ftrace.c:3048)
[ 0.185205] ? __pfx_function_trace_call (kernel/trace/trace_functions.c:210)
[ 0.185877] register_ftrace_function_nolock (kernel/trace/ftrace.c:8717)
[ 0.186595] register_ftrace_function (kernel/trace/ftrace.c:8745)
[ 0.187254] ? __pfx_function_trace_call (kernel/trace/trace_functions.c:210)
[ 0.187924] function_trace_init (kernel/trace/trace_functions.c:170)
[ 0.188499] tracing_set_tracer (kernel/trace/trace.c:5916 kernel/trace/trace.c:6349)
[ 0.189088] register_tracer (kernel/trace/trace.c:2391)
[ 0.189642] early_trace_init (kernel/trace/trace.c:11075 kernel/trace/trace.c:11149)
[ 0.190204] start_kernel (init/main.c:970)
[ 0.190732] x86_64_start_reservations (arch/x86/kernel/head64.c:307)
[ 0.191381] x86_64_start_kernel (??:?)
[ 0.191955] common_startup_64 (arch/x86/kernel/head_64.S:419)
[ 0.192534] </TASK>
[ 0.192839] Modules linked in:
[ 0.193267] CR2: 000000000000001c
[ 0.193730] ---[ end trace 0000000000000000 ]---
-- Steve
^ permalink raw reply
* Re: [v17,6/7] rust: samples: add a module parameter to the rust_minimal sample
From: Andreas Hindborg @ 2025-08-20 18:21 UTC (permalink / raw)
To: Darin Morrison
Cc: 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, 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: <20250819191133.39413-1-darinmorrison@gmail.com>
"Darin Morrison" <darinmorrison@gmail.com> writes:
>> Showcase the rust module parameter support by adding a module parameter to
>> the `rust_minimal` sample.
>>
>> Reviewed-by: Benno Lossin <lossin@kernel.org>
>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>> ---
>> samples/rust/rust_minimal.rs | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>> diff --git a/samples/rust/rust_minimal.rs b/samples/rust/rust_minimal.rs
>> index 1fc7a1be6b6d..8eb9583571d7 100644
>> --- a/samples/rust/rust_minimal.rs
>> +++ b/samples/rust/rust_minimal.rs
>> @@ -10,6 +10,12 @@
>> authors: ["Rust for Linux Contributors"],
>> description: "Rust minimal sample",
>> license: "GPL",
>> + params: {
>> + test_parameter: i64 {
>> + default: 1,
>> + description: "This parameter has a default of 1",
>> + },
>> + },
>
> Thanks for the patches.
>
> I've been using these in a new PCI device driver module and noticed
> that the inclusion of `params:` in the rustdoc test here causes the
> `rusttest` target to fail with a linker error (below) complaining about
> undefined references for `rust_helper_atomic_try_cmpxchg_relaxed` and
> `rust_helper_atomic_set_release`.
>
> Building a real module and using the `params:` field seems to work
> fine though so it must be something specific to the test configuration.
>
> Any ideas how to fix this?
Thanks for reporting! I don't have that issue locally. Do you have a
tree and a config you can point me to, so I can try to reproduce?
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v6 4/9] scsi: Always define blogic_pci_tbl structure
From: Nathan Chancellor @ 2025-08-20 16:11 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Alexey Gladkov, Nicolas Schier, Masahiro Yamada, Petr Pavlu,
Luis Chamberlain, Sami Tolvanen, Daniel Gomez, linux-kernel,
linux-modules, linux-kbuild, Khalid Aziz, linux-scsi,
James Bottomley, Arnd Bergmann, Damien Le Moal
In-Reply-To: <yq18qjeyd4a.fsf@ca-mkp.ca.oracle.com>
On Tue, Aug 19, 2025 at 09:52:10PM -0400, Martin K. Petersen wrote:
> >> Applied to 6.18/scsi-staging, thanks!
> >
> > I think I will need this change to apply patch 7 [1] to kbuild-next
> > without any issues [2]. If there is little risk of conflict, could I
> > take it with your Ack?
>
> Sure, no problem. Dropped the patch from my tree.
>
> Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Thanks a lot!
^ permalink raw reply
* Re: [PATCH v6 4/9] scsi: Always define blogic_pci_tbl structure
From: Martin K. Petersen @ 2025-08-20 1:52 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Martin K. Petersen, Alexey Gladkov, Nicolas Schier,
Masahiro Yamada, Petr Pavlu, Luis Chamberlain, Sami Tolvanen,
Daniel Gomez, linux-kernel, linux-modules, linux-kbuild,
Khalid Aziz, linux-scsi, James Bottomley, Arnd Bergmann,
Damien Le Moal
In-Reply-To: <20250819071817.GA1540193@ax162>
Hi Nathan!
>> Applied to 6.18/scsi-staging, thanks!
>
> I think I will need this change to apply patch 7 [1] to kbuild-next
> without any issues [2]. If there is little risk of conflict, could I
> take it with your Ack?
Sure, no problem. Dropped the patch from my tree.
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
--
Martin K. Petersen
^ permalink raw reply
* Re: [PATCH v4] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES
From: Vlastimil Babka @ 2025-08-19 20:44 UTC (permalink / raw)
To: David Hildenbrand, Daniel Gomez, Linus Torvalds,
Matthias Maennich, Jonathan Corbet, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Nathan Chancellor, Nicolas Schier, Alexander Viro,
Christian Brauner, Jan Kara
Cc: Christoph Hellwig, Peter Zijlstra, Shivank Garg,
Greg Kroah-Hartman, Jiri Slaby (SUSE), Stephen Rothwell,
linux-doc, linux-kernel, linux-modules, linux-kbuild,
linux-fsdevel
In-Reply-To: <8334f7f9-065f-40b9-9c1e-95223da7980d@redhat.com>
On 8/8/25 4:17 PM, David Hildenbrand wrote:
> On 08.08.25 15:28, Vlastimil Babka wrote:
>> Christoph suggested that the explicit _GPL_ can be dropped from the
>> module namespace export macro, as it's intended for in-tree modules
>> only. It would be possible to restrict it technically, but it was
>> pointed out [2] that some cases of using an out-of-tree build of an
>> in-tree module with the same name are legitimate.
>
> I'm wondering if we could revisit that idea later, and have a config
> option that enables that. The use cases so far were mostly around
> testing IIRC, where people already run their own debug kernel or sth.
> like that.
I don't know. It made sense to do this in-tree restriction when it
looked like it could be done unconditionally. But if it would need to be
opt-in config, I think there's little gain. As noted in the lwn
coverage, the metadata can be easily faked anyway. AFAIK the only
serious module loading restriction is then the module signing, so this
would be just a mostly pointless config option?
^ permalink raw reply
* Re: [v17,6/7] rust: samples: add a module parameter to the rust_minimal sample
From: Darin Morrison @ 2025-08-19 19:11 UTC (permalink / raw)
To: a.hindborg
Cc: 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, 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: <20250711-module-params-v3-v17-6-cf9b10d4923d@kernel.org>
> Showcase the rust module parameter support by adding a module parameter to
> the `rust_minimal` sample.
>
> Reviewed-by: Benno Lossin <lossin@kernel.org>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
> ---
> samples/rust/rust_minimal.rs | 10 ++++++++++
> 1 file changed, 10 insertions(+)
> diff --git a/samples/rust/rust_minimal.rs b/samples/rust/rust_minimal.rs
> index 1fc7a1be6b6d..8eb9583571d7 100644
> --- a/samples/rust/rust_minimal.rs
> +++ b/samples/rust/rust_minimal.rs
> @@ -10,6 +10,12 @@
> authors: ["Rust for Linux Contributors"],
> description: "Rust minimal sample",
> license: "GPL",
> + params: {
> + test_parameter: i64 {
> + default: 1,
> + description: "This parameter has a default of 1",
> + },
> + },
Thanks for the patches.
I've been using these in a new PCI device driver module and noticed
that the inclusion of `params:` in the rustdoc test here causes the
`rusttest` target to fail with a linker error (below) complaining about
undefined references for `rust_helper_atomic_try_cmpxchg_relaxed` and
`rust_helper_atomic_set_release`.
Building a real module and using the `params:` field seems to work
fine though so it must be something specific to the test configuration.
Any ideas how to fix this?
---
RUSTDOC T rust/macros/lib.rs
running 10 tests
ii....... 9/10
rust/macros/lib.rs - module (line 61) --- FAILED
failures:
---- rust/macros/lib.rs - module (line 61) stdout ----
error: linking with `cc` failed: exit status: 1
|
= note: "cc" "-m64" "/tmp/rustcVbJoqH/symbols.o" "<2 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic" "./rust/test/{libkernel.rlib,libuapi.rlib,libbindings.rlib,libbuild_error.rlib,libpin_init.rlib,libffi.rlib}.rlib" "<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib/{libstd-*,libpanic_unwind-*,libobject-*,libmemchr-*,libaddr2line-*,libgimli-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libminiz_oxide-*,libadler2-*,libunwind-*,libcfg_if-*,liblibc-*,librustc_std_workspace_core-*,liballoc-*,libcore-*,libcompiler_builtins-*}.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-L" "/tmp/rustcVbJoqH/raw-dylibs" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "./rust/test" "-L" "<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "/tmp/rustdoctestTFYhZ1/rust_out" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs"
= note: some arguments are omitted. use `--verbose` to show all linker arguments
= note: /usr/bin/ld: ./rust/test/libkernel.rlib(kernel.kernel.a8a3768e1a8b2c2e-cgu.3.rcgu.o): in function `kernel::sync::set_once::SetOnce<T>::populate':
kernel.a8a3768e1a8b2c2e-cgu.3:(.text._ZN6kernel4sync8set_once16SetOnce$LT$T$GT$8populate17hab8d57b99b7ebbcbE+0xd3): undefined reference to `rust_helper_atomic_try_cmpxchg_relaxed'
/usr/bin/ld: kernel.a8a3768e1a8b2c2e-cgu.3:(.text._ZN6kernel4sync8set_once16SetOnce$LT$T$GT$8populate17hab8d57b99b7ebbcbE+0x2a8): undefined reference to `rust_helper_atomic_set_release'
collect2: error: ld returned 1 exit status
= note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
= note: use the `-l` flag to specify native libraries to link
^ permalink raw reply
* Re: modprobe returns 0 upon -EEXIST from insmod
From: Christophe Leroy @ 2025-08-19 14:32 UTC (permalink / raw)
To: Lucas De Marchi, Petr Pavlu; +Cc: Phil Sutter, linux-modules, Yi Chen
In-Reply-To: <i4ayzta5zgltyubg6bfr4mwqhl6goyh73lyc7j7m3vngvpooi3@boorlngxpi52>
Le 19/08/2025 à 16:17, Lucas De Marchi a écrit :
> On Tue, Aug 19, 2025 at 10:52:16AM +0200, Petr Pavlu wrote:
>> On 8/18/25 11:34 AM, Phil Sutter wrote:
>>> On Sun, Aug 17, 2025 at 05:54:27PM +0200, Christophe Leroy wrote:
>>>> Le 17/08/2025 à 01:33, Phil Sutter a écrit :
>>>>> [Vous ne recevez pas souvent de courriers de phil@nwl.cc. D?couvrez
>>>>> pourquoi ceci est important ? https://aka.ms/
>>>>> LearnAboutSenderIdentification ]
>>>>>
>>>>> Hi,
>>>>>
>>>>> I admittedly didn't fully analyze the cause, but on my system a
>>>>> call to:
>>>>>
>>>>> # insmod /lib/module/$(uname -r)/kernel/net/netfilter/
>>>>> nf_conntrack_ftp.ko
>>>>>
>>>>> fails with -EEXIST (due to a previous call to 'nfct add helper ftp
>>>>> inet
>>>>> tcp'). A call to:
>>>>>
>>>>> # modprobe nf_conntrack_ftp
>>>>>
>>>>> though returns 0 even though module loading fails. Is there a bug in
>>>>> modprobe error status handling?
>>>>>
>>>>
>>>> Read the man page : https://eur01.safelinks.protection.outlook.com/?
>>>> url=https%3A%2F%2Flinux.die.net%2Fman%2F8%2Fmodprobe&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C2c842a011e454a06da1708dddf2b37a7%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638912098887559261%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QFjpi0HYpLQjzCxuNLgEtq44XzUbyKy8VRAGec5H7Ok%3D&reserved=0
>>>>
>>>> In the man page I see:
>>>>
>>>> Normally, modprobe will succeed (and do nothing) if told to
>>>> insert a module which is already present or to remove a module which
>>>> isn't present.
>>>
>>> This is not a case of already inserted module, it is not loaded before
>>> the call to modprobe. It is the module_init callback
>>> nf_conntrack_ftp_init() which returns -EEXIST it received from
>>> nf_conntrack_helpers_register().
>
> is this a real failure condition or something benign like "if it's
> already registered, there's nothing to do"?
My understanding from Phil's explanation is: it is something serious
that says something like "There is already something else registered on
that UDP Port, I can't register the conntrack helper on that port".
Christophe
>
>>>
>>> Can't user space distinguish the two causes of -EEXIST? Or in other
>>> words, is use of -EEXIST in module_init callbacks problematic?
>>
>> Unfortunately, error return codes from (f)init_module cannot be reliably
>> depended upon. For instance, cpufreq drivers have similar behavior of
>> returning -EEXIST when another cpufreq driver is already registered.
>> Returning this code unexpectedly can then confuse kmod, as it interprets
>> -EEXIST to mean "the module is already loaded" [1].
>
> well, it's not that it can't be relied on. There's 1 exit code that is
> treated specially, EEXISTS, because that error is used by the module
> loading part, before the module_init call, to signify the module is
> already loaded.
>
>>
>> I have thought about this problem before. We might fix the main
>> problematic occurrences, but we can't really audit all the code that
>> module init functions can invoke. I then wonder if it would make sense
>> for the module loader to warn about any -EEXIST returned by a module's
>> init function and translate it to -EBUSY.
>
> If it's a failure condition then yes, -EBUSY looks appropriate.
>
> Lucas De Marchi
>
>>
>> Ensuring the reliability of the 0 and -EEXIST return codes from
>> (f)init_module should help user space.
>>
>> [1] https://eur01.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fgithub.com%2Fkmod-
>> project%2Fkmod%2Fblob%2F695fd084a727cf76f51b129b67d5a4be1d6db32e%2Flibkmod%2Flibkmod-module.c%23L1087&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C2c842a011e454a06da1708dddf2b37a7%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638912098887579771%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=A2B0UH9D47p53Jif4ppLAaiDl6MDIX6ZFjUNik5Cmis%3D&reserved=0
>>
>> -- Petr
^ permalink raw reply
* Re: modprobe returns 0 upon -EEXIST from insmod
From: Lucas De Marchi @ 2025-08-19 14:17 UTC (permalink / raw)
To: Petr Pavlu; +Cc: Phil Sutter, Christophe Leroy, linux-modules, Yi Chen
In-Reply-To: <02be4b86-330e-4f93-ba79-8218d05659ba@suse.com>
On Tue, Aug 19, 2025 at 10:52:16AM +0200, Petr Pavlu wrote:
>On 8/18/25 11:34 AM, Phil Sutter wrote:
>> On Sun, Aug 17, 2025 at 05:54:27PM +0200, Christophe Leroy wrote:
>>> Le 17/08/2025 à 01:33, Phil Sutter a écrit :
>>>> [Vous ne recevez pas souvent de courriers de phil@nwl.cc. D?couvrez pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification ]
>>>>
>>>> Hi,
>>>>
>>>> I admittedly didn't fully analyze the cause, but on my system a call to:
>>>>
>>>> # insmod /lib/module/$(uname -r)/kernel/net/netfilter/nf_conntrack_ftp.ko
>>>>
>>>> fails with -EEXIST (due to a previous call to 'nfct add helper ftp inet
>>>> tcp'). A call to:
>>>>
>>>> # modprobe nf_conntrack_ftp
>>>>
>>>> though returns 0 even though module loading fails. Is there a bug in
>>>> modprobe error status handling?
>>>>
>>>
>>> Read the man page : https://linux.die.net/man/8/modprobe
>>>
>>> In the man page I see:
>>>
>>> Normally, modprobe will succeed (and do nothing) if told to
>>> insert a module which is already present or to remove a module which
>>> isn't present.
>>
>> This is not a case of already inserted module, it is not loaded before
>> the call to modprobe. It is the module_init callback
>> nf_conntrack_ftp_init() which returns -EEXIST it received from
>> nf_conntrack_helpers_register().
is this a real failure condition or something benign like "if it's
already registered, there's nothing to do"?
>>
>> Can't user space distinguish the two causes of -EEXIST? Or in other
>> words, is use of -EEXIST in module_init callbacks problematic?
>
>Unfortunately, error return codes from (f)init_module cannot be reliably
>depended upon. For instance, cpufreq drivers have similar behavior of
>returning -EEXIST when another cpufreq driver is already registered.
>Returning this code unexpectedly can then confuse kmod, as it interprets
>-EEXIST to mean "the module is already loaded" [1].
well, it's not that it can't be relied on. There's 1 exit code that is
treated specially, EEXISTS, because that error is used by the module
loading part, before the module_init call, to signify the module is
already loaded.
>
>I have thought about this problem before. We might fix the main
>problematic occurrences, but we can't really audit all the code that
>module init functions can invoke. I then wonder if it would make sense
>for the module loader to warn about any -EEXIST returned by a module's
>init function and translate it to -EBUSY.
If it's a failure condition then yes, -EBUSY looks appropriate.
Lucas De Marchi
>
>Ensuring the reliability of the 0 and -EEXIST return codes from
>(f)init_module should help user space.
>
>[1] https://github.com/kmod-project/kmod/blob/695fd084a727cf76f51b129b67d5a4be1d6db32e/libkmod/libkmod-module.c#L1087
>
>-- Petr
^ permalink raw reply
* [PATCH] module: Remove unused __INIT*_OR_MODULE macros
From: Petr Pavlu @ 2025-08-19 12:13 UTC (permalink / raw)
To: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen
Cc: linux-modules, linux-kernel
Remove the __INIT_OR_MODULE, __INITDATA_OR_MODULE and
__INITRODATA_OR_MODULE macros. These were introduced in commit 8b5a10fc6fd0
("x86: properly annotate alternatives.c"). Only __INITRODATA_OR_MODULE was
ever used, in arch/x86/kernel/alternative.c. In 2011, commit dc326fca2b64
("x86, cpu: Clean up and unify the NOP selection infrastructure") removed
this usage.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
include/linux/module.h | 6 ------
1 file changed, 6 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 3319a5269d28..e9e6eeb042aa 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -151,16 +151,10 @@ extern void cleanup_module(void);
#define __init_or_module
#define __initdata_or_module
#define __initconst_or_module
-#define __INIT_OR_MODULE .text
-#define __INITDATA_OR_MODULE .data
-#define __INITRODATA_OR_MODULE .section ".rodata","a",%progbits
#else
#define __init_or_module __init
#define __initdata_or_module __initdata
#define __initconst_or_module __initconst
-#define __INIT_OR_MODULE __INIT
-#define __INITDATA_OR_MODULE __INITDATA
-#define __INITRODATA_OR_MODULE __INITRODATA
#endif /*CONFIG_MODULES*/
struct module_kobject *lookup_or_create_module_kobject(const char *name);
base-commit: be48bcf004f9d0c9207ff21d0edb3b42f253829e
--
2.50.1
^ permalink raw reply related
* [PATCH] params: Replace __modinit with __init_or_module
From: Petr Pavlu @ 2025-08-19 12:12 UTC (permalink / raw)
To: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen
Cc: Shyam Saini, Rasmus Villemoes, linux-modules, linux-kernel
Remove the custom __modinit macro from kernel/params.c and instead use the
common __init_or_module macro from include/linux/module.h. Both provide the
same functionality.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
kernel/params.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/kernel/params.c b/kernel/params.c
index b92d64161b75..19bb04f10372 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -595,12 +595,6 @@ static ssize_t param_attr_store(const struct module_attribute *mattr,
}
#endif
-#ifdef CONFIG_MODULES
-#define __modinit
-#else
-#define __modinit __init
-#endif
-
#ifdef CONFIG_SYSFS
void kernel_param_lock(struct module *mod)
{
@@ -625,9 +619,9 @@ EXPORT_SYMBOL(kernel_param_unlock);
* create file in sysfs. Returns an error on out of memory. Always cleans up
* if there's an error.
*/
-static __modinit int add_sysfs_param(struct module_kobject *mk,
- const struct kernel_param *kp,
- const char *name)
+static __init_or_module int add_sysfs_param(struct module_kobject *mk,
+ const struct kernel_param *kp,
+ const char *name)
{
struct module_param_attrs *new_mp;
struct attribute **new_attrs;
@@ -760,7 +754,8 @@ void destroy_params(const struct kernel_param *params, unsigned num)
params[i].ops->free(params[i].arg);
}
-struct module_kobject __modinit * lookup_or_create_module_kobject(const char *name)
+struct module_kobject * __init_or_module
+lookup_or_create_module_kobject(const char *name)
{
struct module_kobject *mk;
struct kobject *kobj;
base-commit: be48bcf004f9d0c9207ff21d0edb3b42f253829e
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v4] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES
From: Christian Brauner @ 2025-08-19 9:44 UTC (permalink / raw)
To: Daniel Gomez
Cc: Vlastimil Babka, Christoph Hellwig, Peter Zijlstra,
David Hildenbrand, Shivank Garg, Greg Kroah-Hartman,
Jiri Slaby (SUSE), Stephen Rothwell, linux-doc, linux-kernel,
linux-modules, linux-kbuild, linux-fsdevel, Nicolas Schier,
Daniel Gomez, Linus Torvalds, Matthias Maennich, Jonathan Corbet,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Nathan Chancellor,
Alexander Viro, Jan Kara
In-Reply-To: <6cce2564-04f2-44ab-96d3-2f47fc221591@kernel.org>
On Fri, Aug 15, 2025 at 05:39:54PM +0200, Daniel Gomez wrote:
>
>
> On 15/08/2025 07.25, Christian Brauner wrote:
> > On Tue, Aug 12, 2025 at 09:54:43AM +0200, Daniel Gomez wrote:
> >> On 11/08/2025 07.18, Christian Brauner wrote:j
> >>> On Fri, 08 Aug 2025 15:28:47 +0200, Vlastimil Babka wrote:
> >>>> Christoph suggested that the explicit _GPL_ can be dropped from the
> >>>> module namespace export macro, as it's intended for in-tree modules
> >>>> only. It would be possible to restrict it technically, but it was
> >>>> pointed out [2] that some cases of using an out-of-tree build of an
> >>>> in-tree module with the same name are legitimate. But in that case those
> >>>> also have to be GPL anyway so it's unnecessary to spell it out in the
> >>>> macro name.
> >>>>
> >>>> [...]
> >>>
> >>> Ok, so last I remember we said that this is going upstream rather sooner
> >>> than later before we keep piling on users. If that's still the case I'll
> >>> take it via vfs.fixes unless I hear objections.
> >>
> >> This used to go through Masahiro's kbuild tree. However, since he is not
> >> available anymore [1] I think it makes sense that this goes through the modules
> >> tree. The only reason we waited until rc1 was released was because of Greg's
> >> advise [2]. Let me know if that makes sense to you and if so, I'll merge this
> >> ASAP.
> >
> > At this point it would mean messing up all of vfs.fixes to drop it from
> > there. So I'd just leave it in there and send it to Linus.
>
> Got it. I was waiting for confirmation before taking it into the modules tree,
> and I agree that at this point it makes sense to keep it in vfs.fixes.
>
> > Next time I know where it'll end up.
>
> Can you clarify what you mean by this?
Next time I know that you are responsible for taking such patches. :)
^ permalink raw reply
* Re: modprobe returns 0 upon -EEXIST from insmod
From: Petr Pavlu @ 2025-08-19 8:52 UTC (permalink / raw)
To: Phil Sutter, Christophe Leroy, Lucas De Marchi; +Cc: linux-modules, Yi Chen
In-Reply-To: <aKLzsAX14ybEjHfJ@orbyte.nwl.cc>
On 8/18/25 11:34 AM, Phil Sutter wrote:
> On Sun, Aug 17, 2025 at 05:54:27PM +0200, Christophe Leroy wrote:
>> Le 17/08/2025 à 01:33, Phil Sutter a écrit :
>>> [Vous ne recevez pas souvent de courriers de phil@nwl.cc. D?couvrez pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> Hi,
>>>
>>> I admittedly didn't fully analyze the cause, but on my system a call to:
>>>
>>> # insmod /lib/module/$(uname -r)/kernel/net/netfilter/nf_conntrack_ftp.ko
>>>
>>> fails with -EEXIST (due to a previous call to 'nfct add helper ftp inet
>>> tcp'). A call to:
>>>
>>> # modprobe nf_conntrack_ftp
>>>
>>> though returns 0 even though module loading fails. Is there a bug in
>>> modprobe error status handling?
>>>
>>
>> Read the man page : https://linux.die.net/man/8/modprobe
>>
>> In the man page I see:
>>
>> Normally, modprobe will succeed (and do nothing) if told to
>> insert a module which is already present or to remove a module which
>> isn't present.
>
> This is not a case of already inserted module, it is not loaded before
> the call to modprobe. It is the module_init callback
> nf_conntrack_ftp_init() which returns -EEXIST it received from
> nf_conntrack_helpers_register().
>
> Can't user space distinguish the two causes of -EEXIST? Or in other
> words, is use of -EEXIST in module_init callbacks problematic?
Unfortunately, error return codes from (f)init_module cannot be reliably
depended upon. For instance, cpufreq drivers have similar behavior of
returning -EEXIST when another cpufreq driver is already registered.
Returning this code unexpectedly can then confuse kmod, as it interprets
-EEXIST to mean "the module is already loaded" [1].
I have thought about this problem before. We might fix the main
problematic occurrences, but we can't really audit all the code that
module init functions can invoke. I then wonder if it would make sense
for the module loader to warn about any -EEXIST returned by a module's
init function and translate it to -EBUSY.
Ensuring the reliability of the 0 and -EEXIST return codes from
(f)init_module should help user space.
[1] https://github.com/kmod-project/kmod/blob/695fd084a727cf76f51b129b67d5a4be1d6db32e/libkmod/libkmod-module.c#L1087
-- Petr
^ permalink raw reply
* Re: [PATCH v6 4/9] scsi: Always define blogic_pci_tbl structure
From: Nathan Chancellor @ 2025-08-19 7:18 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Alexey Gladkov, Nicolas Schier, Masahiro Yamada, Petr Pavlu,
Luis Chamberlain, Sami Tolvanen, Daniel Gomez, linux-kernel,
linux-modules, linux-kbuild, Khalid Aziz, linux-scsi,
James Bottomley, Arnd Bergmann, Damien Le Moal
In-Reply-To: <yq1v7mkxe2h.fsf@ca-mkp.ca.oracle.com>
Hi Martin,
On Mon, Aug 18, 2025 at 10:04:02PM -0400, Martin K. Petersen wrote:
>
> Alexey,
>
> > The blogic_pci_tbl structure is used by the MODULE_DEVICE_TABLE macro.
> > There is no longer a need to protect it with the MODULE condition,
> > since this no longer causes the compiler to warn about an unused
> > variable.
> >
> > To avoid warnings when -Wunused-const-variable option is used, mark it
> > as __maybe_unused for such configuration.
>
> Applied to 6.18/scsi-staging, thanks!
I think I will need this change to apply patch 7 [1] to kbuild-next
without any issues [2]. If there is little risk of conflict, could I
take it with your Ack? Another option would be getting it into 6.17 as a
fix so that I could back merge Linus's tree and apply the series on top.
I am already going to have to do that for the pinctrl change that Linus
W took [3].
[1]: https://lore.kernel.org/22b36a5807d943a84431298c18b41d093e01c371.1755170493.git.legion@kernel.org/
[2]: https://lore.kernel.org/aDWoCU2YrxaCBi42@example.org/
[3]: https://lore.kernel.org/CACRpkdZ9oyJ4aJ5Dcp_Dtv5qoiSo+g5cO7Uf4PmHgv_Z423onQ@mail.gmail.com/
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH v6 4/9] scsi: Always define blogic_pci_tbl structure
From: Martin K. Petersen @ 2025-08-19 2:04 UTC (permalink / raw)
To: Alexey Gladkov
Cc: Nathan Chancellor, Nicolas Schier, Masahiro Yamada, Petr Pavlu,
Luis Chamberlain, Sami Tolvanen, Daniel Gomez, linux-kernel,
linux-modules, linux-kbuild, Khalid Aziz, Martin K. Petersen,
linux-scsi, James Bottomley, Arnd Bergmann, Damien Le Moal
In-Reply-To: <93ca6c988e2d8a294ae0941747a6e654e6e8e8b8.1755170493.git.legion@kernel.org>
Alexey,
> The blogic_pci_tbl structure is used by the MODULE_DEVICE_TABLE macro.
> There is no longer a need to protect it with the MODULE condition,
> since this no longer causes the compiler to warn about an unused
> variable.
>
> To avoid warnings when -Wunused-const-variable option is used, mark it
> as __maybe_unused for such configuration.
Applied to 6.18/scsi-staging, thanks!
--
Martin K. Petersen
^ permalink raw reply
* [PATCH v7 8/8] kbuild: vmlinux.unstripped should always depend on .vmlinux.export.o
From: Alexey Gladkov @ 2025-08-18 16:55 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Petr Pavlu, Luis Chamberlain,
Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild, Alexey Gladkov
In-Reply-To: <cover.1755535876.git.legion@kernel.org>
Since .vmlinux.export.c is used to add generated by modpost modaliases
for builtin modules the .vmlinux.export.o is no longer optional and
should always be created. The generation of this file is not dependent
on CONFIG_MODULES.
Signed-off-by: Alexey Gladkov <legion@kernel.org>
---
scripts/Makefile.vmlinux | 9 ++-------
scripts/link-vmlinux.sh | 5 +----
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
index fcc188d26ead1..dbbe3bf0cf234 100644
--- a/scripts/Makefile.vmlinux
+++ b/scripts/Makefile.vmlinux
@@ -53,11 +53,6 @@ endif
# vmlinux.unstripped
# ---------------------------------------------------------------------------
-ifdef CONFIG_MODULES
-targets += .vmlinux.export.o
-vmlinux.unstripped: .vmlinux.export.o
-endif
-
ifdef CONFIG_ARCH_WANTS_PRE_LINK_VMLINUX
vmlinux.unstripped: arch/$(SRCARCH)/tools/vmlinux.arch.o
@@ -72,8 +67,8 @@ cmd_link_vmlinux = \
$< "$(LD)" "$(KBUILD_LDFLAGS)" "$(LDFLAGS_vmlinux)" "$@"; \
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
-targets += vmlinux.unstripped
-vmlinux.unstripped: scripts/link-vmlinux.sh vmlinux.o $(KBUILD_LDS) FORCE
+targets += vmlinux.unstripped .vmlinux.export.o
+vmlinux.unstripped: scripts/link-vmlinux.sh vmlinux.o .vmlinux.export.o $(KBUILD_LDS) FORCE
+$(call if_changed_dep,link_vmlinux)
ifdef CONFIG_DEBUG_INFO_BTF
vmlinux.unstripped: $(RESOLVE_BTFIDS)
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 51367c2bfc21e..433849ff7529e 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -73,10 +73,7 @@ vmlinux_link()
objs="${objs} .builtin-dtbs.o"
fi
- if is_enabled CONFIG_MODULES; then
- objs="${objs} .vmlinux.export.o"
- fi
-
+ objs="${objs} .vmlinux.export.o"
objs="${objs} init/version-timestamp.o"
if [ "${SRCARCH}" = "um" ]; then
--
2.50.1
^ permalink raw reply related
* [PATCH v7 7/8] modpost: Create modalias for builtin modules
From: Alexey Gladkov @ 2025-08-18 16:55 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Petr Pavlu, Luis Chamberlain,
Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild, Alexey Gladkov,
Masahiro Yamada, Stephen Rothwell
In-Reply-To: <cover.1755535876.git.legion@kernel.org>
For some modules, modalias is generated using the modpost utility and
the section is added to the module file.
When a module is added inside vmlinux, modpost does not generate
modalias for such modules and the information is lost.
As a result kmod (which uses modules.builtin.modinfo in userspace)
cannot determine that modalias is handled by a builtin kernel module.
$ cat /sys/devices/pci0000:00/0000:00:14.0/modalias
pci:v00008086d0000A36Dsv00001043sd00008694bc0Csc03i30
$ modinfo xhci_pci
name: xhci_pci
filename: (builtin)
license: GPL
file: drivers/usb/host/xhci-pci
description: xHCI PCI Host Controller Driver
Missing modalias "pci:v*d*sv*sd*bc0Csc03i30*" which will be generated by
modpost if the module is built separately.
To fix this it is necessary to generate the same modalias for vmlinux as
for the individual modules. Fortunately '.vmlinux.export.o' is already
generated from which '.modinfo' can be extracted in the same way as for
vmlinux.o.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Alexey Gladkov <legion@kernel.org>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/linux/module.h | 4 ----
scripts/Makefile.vmlinux | 5 ++++-
scripts/mksysmap | 3 +++
scripts/mod/file2alias.c | 16 ++++++++++++++++
scripts/mod/modpost.c | 15 +++++++++++++++
scripts/mod/modpost.h | 2 ++
6 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index e31ee29fac6b7..e135cc79aceea 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -256,14 +256,10 @@ struct module_kobject *lookup_or_create_module_kobject(const char *name);
__PASTE(type, \
__PASTE(__, name)))))
-#ifdef MODULE
/* Creates an alias so file2alias.c can find device table. */
#define MODULE_DEVICE_TABLE(type, name) \
static typeof(name) __mod_device_table(type, name) \
__attribute__ ((used, alias(__stringify(name))))
-#else /* !MODULE */
-#define MODULE_DEVICE_TABLE(type, name)
-#endif
/* Version of form [<epoch>:]<version>[-<extra-version>].
* Or for CVS/RCS ID version, everything but the number is stripped.
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
index fdab5aa90215b..fcc188d26ead1 100644
--- a/scripts/Makefile.vmlinux
+++ b/scripts/Makefile.vmlinux
@@ -89,8 +89,11 @@ endif
remove-section-y := .modinfo
remove-section-$(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS) += '.rel*'
+remove-symbols := -w --strip-symbol='__mod_device_table__*'
+
quiet_cmd_strip_relocs = OBJCOPY $@
- cmd_strip_relocs = $(OBJCOPY) $(addprefix --remove-section=,$(remove-section-y)) $< $@
+ cmd_strip_relocs = $(OBJCOPY) $(addprefix --remove-section=,$(remove-section-y)) \
+ $(remove-symbols) $< $@
targets += vmlinux
vmlinux: vmlinux.unstripped FORCE
diff --git a/scripts/mksysmap b/scripts/mksysmap
index a607a0059d119..c4531eacde202 100755
--- a/scripts/mksysmap
+++ b/scripts/mksysmap
@@ -59,6 +59,9 @@
# EXPORT_SYMBOL (namespace)
/ __kstrtabns_/d
+# MODULE_DEVICE_TABLE (symbol name)
+/ __mod_device_table__/d
+
# ---------------------------------------------------------------------------
# Ignored suffixes
# (do not forget '$' after each pattern)
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 13021266a18f8..7da9735e7ab3e 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1527,5 +1527,21 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
}
}
+ if (mod->is_vmlinux) {
+ struct module_alias *alias;
+
+ /*
+ * If this is vmlinux, record the name of the builtin module.
+ * Traverse the linked list in the reverse order, and set the
+ * builtin_modname unless it has already been set in the
+ * previous call.
+ */
+ list_for_each_entry_reverse(alias, &mod->aliases, node) {
+ if (alias->builtin_modname)
+ break;
+ alias->builtin_modname = xstrndup(modname, modnamelen);
+ }
+ }
+
free(zeros);
}
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 5ca7c268294eb..47c8aa2a69392 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -2067,11 +2067,26 @@ static void write_if_changed(struct buffer *b, const char *fname)
static void write_vmlinux_export_c_file(struct module *mod)
{
struct buffer buf = { };
+ struct module_alias *alias, *next;
buf_printf(&buf,
"#include <linux/export-internal.h>\n");
add_exported_symbols(&buf, mod);
+
+ buf_printf(&buf,
+ "#include <linux/module.h>\n"
+ "#undef __MODULE_INFO_PREFIX\n"
+ "#define __MODULE_INFO_PREFIX\n");
+
+ list_for_each_entry_safe(alias, next, &mod->aliases, node) {
+ buf_printf(&buf, "MODULE_INFO(%s.alias, \"%s\");\n",
+ alias->builtin_modname, alias->str);
+ list_del(&alias->node);
+ free(alias->builtin_modname);
+ free(alias);
+ }
+
write_if_changed(&buf, ".vmlinux.export.c");
free(buf.p);
}
diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h
index 9133e4c3803f0..2aecb8f25c87e 100644
--- a/scripts/mod/modpost.h
+++ b/scripts/mod/modpost.h
@@ -99,10 +99,12 @@ buf_write(struct buffer *buf, const char *s, int len);
* struct module_alias - auto-generated MODULE_ALIAS()
*
* @node: linked to module::aliases
+ * @modname: name of the builtin module (only for vmlinux)
* @str: a string for MODULE_ALIAS()
*/
struct module_alias {
struct list_head node;
+ char *builtin_modname;
char str[];
};
--
2.50.1
^ permalink raw reply related
* [PATCH v7 6/8] modpost: Add modname to mod_device_table alias
From: Alexey Gladkov @ 2025-08-18 16:55 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Petr Pavlu, Luis Chamberlain,
Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild, Alexey Gladkov,
Miguel Ojeda, Andreas Hindborg, Danilo Krummrich, Alex Gaynor,
rust-for-linux
In-Reply-To: <cover.1755535876.git.legion@kernel.org>
At this point, if a symbol is compiled as part of the kernel,
information about which module the symbol belongs to is lost.
To save this it is possible to add the module name to the alias name.
It's not very pretty, but it's possible for now.
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: Andreas Hindborg <a.hindborg@kernel.org>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Alex Gaynor <alex.gaynor@gmail.com>
Cc: rust-for-linux@vger.kernel.org
Signed-off-by: Alexey Gladkov <legion@kernel.org>
Acked-by: Danilo Krummrich <dakr@kernel.org>
---
include/linux/module.h | 14 +++++++++++++-
rust/kernel/device_id.rs | 8 ++++----
scripts/mod/file2alias.c | 18 ++++++++++++++----
3 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 3319a5269d286..e31ee29fac6b7 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -244,10 +244,22 @@ struct module_kobject *lookup_or_create_module_kobject(const char *name);
/* What your module does. */
#define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
+/*
+ * Format: __mod_device_table__kmod_<modname>__<type>__<name>
+ * Parts of the string `__kmod_` and `__` are used as delimiters when parsing
+ * a symbol in file2alias.c
+ */
+#define __mod_device_table(type, name) \
+ __PASTE(__mod_device_table__, \
+ __PASTE(__KBUILD_MODNAME, \
+ __PASTE(__, \
+ __PASTE(type, \
+ __PASTE(__, name)))))
+
#ifdef MODULE
/* Creates an alias so file2alias.c can find device table. */
#define MODULE_DEVICE_TABLE(type, name) \
-static typeof(name) __mod_device_table__##type##__##name \
+static typeof(name) __mod_device_table(type, name) \
__attribute__ ((used, alias(__stringify(name))))
#else /* !MODULE */
#define MODULE_DEVICE_TABLE(type, name)
diff --git a/rust/kernel/device_id.rs b/rust/kernel/device_id.rs
index 70d57814ff79b..62c42da12e9de 100644
--- a/rust/kernel/device_id.rs
+++ b/rust/kernel/device_id.rs
@@ -195,10 +195,10 @@ macro_rules! module_device_table {
($table_type: literal, $module_table_name:ident, $table_name:ident) => {
#[rustfmt::skip]
#[export_name =
- concat!("__mod_device_table__", $table_type,
- "__", module_path!(),
- "_", line!(),
- "_", stringify!($table_name))
+ concat!("__mod_device_table__", line!(),
+ "__kmod_", module_path!(),
+ "__", $table_type,
+ "__", stringify!($table_name))
]
static $module_table_name: [::core::mem::MaybeUninit<u8>; $table_name.raw_ids().size()] =
unsafe { ::core::mem::transmute_copy($table_name.raw_ids()) };
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 00586119a25b7..13021266a18f8 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1476,8 +1476,8 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
{
void *symval;
char *zeros = NULL;
- const char *type, *name;
- size_t typelen;
+ const char *type, *name, *modname;
+ size_t typelen, modnamelen;
static const char *prefix = "__mod_device_table__";
/* We're looking for a section relative symbol */
@@ -1488,10 +1488,20 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
if (ELF_ST_TYPE(sym->st_info) != STT_OBJECT)
return;
- /* All our symbols are of form __mod_device_table__<type>__<name>. */
+ /* All our symbols are of form __mod_device_table__kmod_<modname>__<type>__<name>. */
if (!strstarts(symname, prefix))
return;
- type = symname + strlen(prefix);
+
+ modname = strstr(symname, "__kmod_");
+ if (!modname)
+ return;
+ modname += strlen("__kmod_");
+
+ type = strstr(modname, "__");
+ if (!type)
+ return;
+ modnamelen = type - modname;
+ type += strlen("__");
name = strstr(type, "__");
if (!name)
--
2.50.1
^ permalink raw reply related
* [PATCH v7 5/8] scsi: Always define blogic_pci_tbl structure
From: Alexey Gladkov @ 2025-08-18 16:54 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Petr Pavlu, Luis Chamberlain,
Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild, Alexey Gladkov,
Khalid Aziz, Martin K. Petersen, linux-scsi, James Bottomley,
Arnd Bergmann, Damien Le Moal
In-Reply-To: <cover.1755535876.git.legion@kernel.org>
The blogic_pci_tbl structure is used by the MODULE_DEVICE_TABLE macro.
There is no longer a need to protect it with the MODULE condition, since
this no longer causes the compiler to warn about an unused variable.
To avoid warnings when -Wunused-const-variable option is used, mark it
as __maybe_unused for such configuration.
Cc: Khalid Aziz <khalid@gonehiking.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org
Suggested-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Alexey Gladkov <legion@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
---
drivers/scsi/BusLogic.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index 1f100270cd385..82597bd96525b 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -3715,7 +3715,6 @@ static void __exit blogic_exit(void)
__setup("BusLogic=", blogic_setup);
-#ifdef MODULE
/*static const struct pci_device_id blogic_pci_tbl[] = {
{ PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
@@ -3725,13 +3724,12 @@ __setup("BusLogic=", blogic_setup);
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{ }
};*/
-static const struct pci_device_id blogic_pci_tbl[] = {
+static const struct pci_device_id blogic_pci_tbl[] __maybe_unused = {
{PCI_DEVICE(PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER)},
{PCI_DEVICE(PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER_NC)},
{PCI_DEVICE(PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_FLASHPOINT)},
{0, },
};
-#endif
MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);
module_init(blogic_init);
--
2.50.1
^ permalink raw reply related
* [PATCH v7 4/8] kbuild: extract modules.builtin.modinfo from vmlinux.unstripped
From: Alexey Gladkov @ 2025-08-18 16:54 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Petr Pavlu, Luis Chamberlain,
Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild, Masahiro Yamada,
Alexey Gladkov
In-Reply-To: <cover.1755535876.git.legion@kernel.org>
From: Masahiro Yamada <masahiroy@kernel.org>
Currently, we assume all the data for modules.builtin.modinfo are
available in vmlinux.o.
This makes it impossible for modpost, which is invoked after vmlinux.o,
to add additional module info.
This commit moves the modules.builtin.modinfo rule after modpost.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Alexey Gladkov <legion@kernel.org>
---
scripts/Makefile.vmlinux | 26 ++++++++++++++++++++++++++
scripts/Makefile.vmlinux_o | 26 +-------------------------
2 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
index e2ceeb9e168d4..fdab5aa90215b 100644
--- a/scripts/Makefile.vmlinux
+++ b/scripts/Makefile.vmlinux
@@ -96,6 +96,32 @@ targets += vmlinux
vmlinux: vmlinux.unstripped FORCE
$(call if_changed,strip_relocs)
+# modules.builtin.modinfo
+# ---------------------------------------------------------------------------
+
+OBJCOPYFLAGS_modules.builtin.modinfo := -j .modinfo -O binary
+
+targets += modules.builtin.modinfo
+modules.builtin.modinfo: vmlinux.unstripped FORCE
+ $(call if_changed,objcopy)
+
+# modules.builtin
+# ---------------------------------------------------------------------------
+
+__default: modules.builtin
+
+# The second line aids cases where multiple modules share the same object.
+
+quiet_cmd_modules_builtin = GEN $@
+ cmd_modules_builtin = \
+ tr '\0' '\n' < $< | \
+ sed -n 's/^[[:alnum:]:_]*\.file=//p' | \
+ tr ' ' '\n' | uniq | sed -e 's:^:kernel/:' -e 's/$$/.ko/' > $@
+
+targets += modules.builtin
+modules.builtin: modules.builtin.modinfo FORCE
+ $(call if_changed,modules_builtin)
+
# modules.builtin.ranges
# ---------------------------------------------------------------------------
ifdef CONFIG_BUILTIN_MODULE_RANGES
diff --git a/scripts/Makefile.vmlinux_o b/scripts/Makefile.vmlinux_o
index b024ffb3e2018..23c8751285d79 100644
--- a/scripts/Makefile.vmlinux_o
+++ b/scripts/Makefile.vmlinux_o
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
PHONY := __default
-__default: vmlinux.o modules.builtin.modinfo modules.builtin
+__default: vmlinux.o
include include/config/auto.conf
include $(srctree)/scripts/Kbuild.include
@@ -73,30 +73,6 @@ vmlinux.o: $(initcalls-lds) vmlinux.a $(KBUILD_VMLINUX_LIBS) FORCE
targets += vmlinux.o
-# modules.builtin.modinfo
-# ---------------------------------------------------------------------------
-
-OBJCOPYFLAGS_modules.builtin.modinfo := -j .modinfo -O binary
-
-targets += modules.builtin.modinfo
-modules.builtin.modinfo: vmlinux.o FORCE
- $(call if_changed,objcopy)
-
-# modules.builtin
-# ---------------------------------------------------------------------------
-
-# The second line aids cases where multiple modules share the same object.
-
-quiet_cmd_modules_builtin = GEN $@
- cmd_modules_builtin = \
- tr '\0' '\n' < $< | \
- sed -n 's/^[[:alnum:]:_]*\.file=//p' | \
- tr ' ' '\n' | uniq | sed -e 's:^:kernel/:' -e 's/$$/.ko/' > $@
-
-targets += modules.builtin
-modules.builtin: modules.builtin.modinfo FORCE
- $(call if_changed,modules_builtin)
-
# Add FORCE to the prerequisites of a target to force it to be always rebuilt.
# ---------------------------------------------------------------------------
--
2.50.1
^ permalink raw reply related
* [PATCH v7 3/8] kbuild: keep .modinfo section in vmlinux.unstripped
From: Alexey Gladkov @ 2025-08-18 16:54 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Petr Pavlu, Luis Chamberlain,
Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild, Masahiro Yamada
In-Reply-To: <cover.1755535876.git.legion@kernel.org>
From: Masahiro Yamada <masahiroy@kernel.org>
Keep the .modinfo section during linking, but strip it from the final
vmlinux.
Adjust scripts/mksysmap to exclude modinfo symbols from kallsyms.
This change will allow the next commit to extract the .modinfo section
from the vmlinux.unstripped intermediate.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---
include/asm-generic/vmlinux.lds.h | 2 +-
scripts/Makefile.vmlinux | 2 +-
scripts/mksysmap | 3 +++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index ae2d2359b79e9..cfa63860dfd4c 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -831,6 +831,7 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
/* Required sections not related to debugging. */
#define ELF_DETAILS \
+ .modinfo : { *(.modinfo) } \
.comment 0 : { *(.comment) } \
.symtab 0 : { *(.symtab) } \
.strtab 0 : { *(.strtab) } \
@@ -1044,7 +1045,6 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
*(.discard.*) \
*(.export_symbol) \
*(.no_trim_symbol) \
- *(.modinfo) \
/* ld.bfd warns about .gnu.version* even when not emitted */ \
*(.gnu.version*) \
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
index 4f2d4c3fb7372..e2ceeb9e168d4 100644
--- a/scripts/Makefile.vmlinux
+++ b/scripts/Makefile.vmlinux
@@ -86,7 +86,7 @@ endif
# vmlinux
# ---------------------------------------------------------------------------
-remove-section-y :=
+remove-section-y := .modinfo
remove-section-$(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS) += '.rel*'
quiet_cmd_strip_relocs = OBJCOPY $@
diff --git a/scripts/mksysmap b/scripts/mksysmap
index 3accbdb269ac7..a607a0059d119 100755
--- a/scripts/mksysmap
+++ b/scripts/mksysmap
@@ -79,6 +79,9 @@
/ _SDA_BASE_$/d
/ _SDA2_BASE_$/d
+# MODULE_INFO()
+/ __UNIQUE_ID_modinfo[0-9]*$/d
+
# ---------------------------------------------------------------------------
# Ignored patterns
# (symbols that contain the pattern are ignored)
--
2.50.1
^ permalink raw reply related
* [PATCH v7 2/8] kbuild: always create intermediate vmlinux.unstripped
From: Alexey Gladkov @ 2025-08-18 16:54 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Petr Pavlu, Luis Chamberlain,
Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild, Masahiro Yamada
In-Reply-To: <cover.1755535876.git.legion@kernel.org>
From: Masahiro Yamada <masahiroy@kernel.org>
Generate the intermediate vmlinux.unstripped regardless of
CONFIG_ARCH_VMLINUX_NEEDS_RELOCS.
If CONFIG_ARCH_VMLINUX_NEEDS_RELOCS is unset, vmlinux.unstripped and
vmlinux are identiacal.
This simplifies the build rule, and allows to strip more sections
by adding them to remove-section-y.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---
scripts/Makefile.vmlinux | 45 ++++++++++++++++++++--------------------
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
index b64862dc6f08d..4f2d4c3fb7372 100644
--- a/scripts/Makefile.vmlinux
+++ b/scripts/Makefile.vmlinux
@@ -9,20 +9,6 @@ include $(srctree)/scripts/Makefile.lib
targets :=
-ifdef CONFIG_ARCH_VMLINUX_NEEDS_RELOCS
-vmlinux-final := vmlinux.unstripped
-
-quiet_cmd_strip_relocs = RSTRIP $@
- cmd_strip_relocs = $(OBJCOPY) --remove-section='.rel*' --remove-section=!'.rel*.dyn' $< $@
-
-vmlinux: $(vmlinux-final) FORCE
- $(call if_changed,strip_relocs)
-
-targets += vmlinux
-else
-vmlinux-final := vmlinux
-endif
-
%.o: %.c FORCE
$(call if_changed_rule,cc_o_c)
@@ -61,19 +47,19 @@ targets += .builtin-dtbs-list
ifdef CONFIG_GENERIC_BUILTIN_DTB
targets += .builtin-dtbs.S .builtin-dtbs.o
-$(vmlinux-final): .builtin-dtbs.o
+vmlinux.unstripped: .builtin-dtbs.o
endif
-# vmlinux
+# vmlinux.unstripped
# ---------------------------------------------------------------------------
ifdef CONFIG_MODULES
targets += .vmlinux.export.o
-$(vmlinux-final): .vmlinux.export.o
+vmlinux.unstripped: .vmlinux.export.o
endif
ifdef CONFIG_ARCH_WANTS_PRE_LINK_VMLINUX
-$(vmlinux-final): arch/$(SRCARCH)/tools/vmlinux.arch.o
+vmlinux.unstripped: arch/$(SRCARCH)/tools/vmlinux.arch.o
arch/$(SRCARCH)/tools/vmlinux.arch.o: vmlinux.o FORCE
$(Q)$(MAKE) $(build)=arch/$(SRCARCH)/tools $@
@@ -86,17 +72,30 @@ cmd_link_vmlinux = \
$< "$(LD)" "$(KBUILD_LDFLAGS)" "$(LDFLAGS_vmlinux)" "$@"; \
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
-targets += $(vmlinux-final)
-$(vmlinux-final): scripts/link-vmlinux.sh vmlinux.o $(KBUILD_LDS) FORCE
+targets += vmlinux.unstripped
+vmlinux.unstripped: scripts/link-vmlinux.sh vmlinux.o $(KBUILD_LDS) FORCE
+$(call if_changed_dep,link_vmlinux)
ifdef CONFIG_DEBUG_INFO_BTF
-$(vmlinux-final): $(RESOLVE_BTFIDS)
+vmlinux.unstripped: $(RESOLVE_BTFIDS)
endif
ifdef CONFIG_BUILDTIME_TABLE_SORT
-$(vmlinux-final): scripts/sorttable
+vmlinux.unstripped: scripts/sorttable
endif
+# vmlinux
+# ---------------------------------------------------------------------------
+
+remove-section-y :=
+remove-section-$(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS) += '.rel*'
+
+quiet_cmd_strip_relocs = OBJCOPY $@
+ cmd_strip_relocs = $(OBJCOPY) $(addprefix --remove-section=,$(remove-section-y)) $< $@
+
+targets += vmlinux
+vmlinux: vmlinux.unstripped FORCE
+ $(call if_changed,strip_relocs)
+
# modules.builtin.ranges
# ---------------------------------------------------------------------------
ifdef CONFIG_BUILTIN_MODULE_RANGES
@@ -110,7 +109,7 @@ modules.builtin.ranges: $(srctree)/scripts/generate_builtin_ranges.awk \
modules.builtin vmlinux.map vmlinux.o.map FORCE
$(call if_changed,modules_builtin_ranges)
-vmlinux.map: $(vmlinux-final)
+vmlinux.map: vmlinux.unstripped
@:
endif
--
2.50.1
^ permalink raw reply related
* [PATCH v7 1/8] s390: vmlinux.lds.S: Reorder sections
From: Alexey Gladkov @ 2025-08-18 16:54 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Petr Pavlu, Luis Chamberlain,
Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild, Alexey Gladkov,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev, linux-s390,
kernel test robot
In-Reply-To: <cover.1755535876.git.legion@kernel.org>
In the upcoming changes, the ELF_DETAILS macro will be extended with
the ".modinfo" section, which will cause an error:
>> s390x-linux-ld: .tmp_vmlinux1: warning: allocated section `.modinfo' not in segment
>> s390x-linux-ld: .tmp_vmlinux2: warning: allocated section `.modinfo' not in segment
>> s390x-linux-ld: vmlinux.unstripped: warning: allocated section `.modinfo' not in segment
This happens because the .vmlinux.info use :NONE to override the default
segment and tell the linker to not put the section in any segment at all.
To avoid this, we need to change the sections order that will be placed
in the default segment.
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: linux-s390@vger.kernel.org
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202506062053.zbkFBEnJ-lkp@intel.com/
Signed-off-by: Alexey Gladkov <legion@kernel.org>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
---
arch/s390/kernel/vmlinux.lds.S | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/s390/kernel/vmlinux.lds.S b/arch/s390/kernel/vmlinux.lds.S
index 1c606dfa595d8..feecf1a6ddb44 100644
--- a/arch/s390/kernel/vmlinux.lds.S
+++ b/arch/s390/kernel/vmlinux.lds.S
@@ -209,6 +209,11 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
_end = . ;
+ /* Debugging sections. */
+ STABS_DEBUG
+ DWARF_DEBUG
+ ELF_DETAILS
+
/*
* uncompressed image info used by the decompressor
* it should match struct vmlinux_info
@@ -239,11 +244,6 @@ SECTIONS
#endif
} :NONE
- /* Debugging sections. */
- STABS_DEBUG
- DWARF_DEBUG
- ELF_DETAILS
-
/*
* Make sure that the .got.plt is either completely empty or it
* contains only the three reserved double words.
--
2.50.1
^ permalink raw reply related
* [PATCH v7 0/8] Add generated modalias to modules.builtin.modinfo
From: Alexey Gladkov @ 2025-08-18 16:54 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Petr Pavlu, Luis Chamberlain,
Sami Tolvanen, Daniel Gomez
Cc: linux-kernel, linux-modules, linux-kbuild, Alexey Gladkov
The modules.builtin.modinfo file is used by userspace (kmod to be specific) to
get information about builtin modules. Among other information about the module,
information about module aliases is stored. This is very important to determine
that a particular modalias will be handled by a module that is inside the
kernel.
There are several mechanisms for creating modalias for modules:
The first is to explicitly specify the MODULE_ALIAS of the macro. In this case,
the aliases go into the '.modinfo' section of the module if it is compiled
separately or into vmlinux.o if it is builtin into the kernel.
The second is the use of MODULE_DEVICE_TABLE followed by the use of the
modpost utility. In this case, vmlinux.o no longer has this information and
does not get it into modules.builtin.modinfo.
For example:
$ modinfo pci:v00008086d0000A36Dsv00001043sd00008694bc0Csc03i30
modinfo: ERROR: Module pci:v00008086d0000A36Dsv00001043sd00008694bc0Csc03i30 not found.
$ modinfo xhci_pci
name: xhci_pci
filename: (builtin)
license: GPL
file: drivers/usb/host/xhci-pci
description: xHCI PCI Host Controller Driver
The builtin module is missing alias "pci:v*d*sv*sd*bc0Csc03i30*" which will be
generated by modpost if the module is built separately.
To fix this it is necessary to add the generated by modpost modalias to
modules.builtin.modinfo. Fortunately modpost already generates .vmlinux.export.c
for exported symbols. It is possible to add `.modinfo` for builtin modules and
modify the build system so that `.modinfo` section is extracted from the
intermediate vmlinux after modpost is executed.
---
Notes:
- v7:
* Reorder patches to avoid unnecessary linker warnings on s390.
* Drop the patch for pinctrl since it's already been applied.
* v6: https://lore.kernel.org/all/cover.1755170493.git.legion@kernel.org/
- v6:
* Rebase to v6.17-rc1-16-g8742b2d8935f to pick up the fixes made by Masahiro Yamada.
* Fix an issue on i386 configs caused by the use of string_32.h.
* v5: https://lore.kernel.org/all/cover.1753354215.git.legion@kernel.org/
- v5:
* Rebase to v6.16-rc6-281-gf4a40a4282f4 to pick up the fixes made by Masahiro Yamada.
* Attempt to fix linker warning on s390.
* Fix typo in pinctrl/meson found by the kernel test robot.
* v4: https://lore.kernel.org/all/cover.1750511018.git.legion@kernel.org/
- v4:
* Rework the patchset based on top of Masahiro Yamada's patches.
* Add removal of unnecessary __mod_device_table__* symbols to avoid symbol
table growth in vmlinux.
* rust code takes into account changes in __mod_device_table__*.
* v3: https://lore.kernel.org/all/cover.1748335606.git.legion@kernel.org/
- v3:
* Add `Reviewed-by` tag to patches from Petr Pavlu.
* Rebase to v6.15.
* v2: https://lore.kernel.org/all/20250509164237.2886508-1-legion@kernel.org/
- v2:
* Drop patch for mfd because it was already applied and is in linux-next.
* The generation of aliases for builtin modules has been redone as
suggested by Masahiro Yamada.
* Rebase to v6.15-rc5-136-g9c69f8884904
* v1: https://lore.kernel.org/all/cover.1745591072.git.legion@kernel.org/
Alexey Gladkov (5):
s390: vmlinux.lds.S: Reorder sections
scsi: Always define blogic_pci_tbl structure
modpost: Add modname to mod_device_table alias
modpost: Create modalias for builtin modules
kbuild: vmlinux.unstripped should always depend on .vmlinux.export.o
Masahiro Yamada (3):
kbuild: always create intermediate vmlinux.unstripped
kbuild: keep .modinfo section in vmlinux.unstripped
kbuild: extract modules.builtin.modinfo from vmlinux.unstripped
arch/s390/kernel/vmlinux.lds.S | 10 ++--
drivers/scsi/BusLogic.c | 4 +-
include/asm-generic/vmlinux.lds.h | 2 +-
include/linux/module.h | 18 ++++++--
rust/kernel/device_id.rs | 8 ++--
scripts/Makefile.vmlinux | 77 ++++++++++++++++++++-----------
scripts/Makefile.vmlinux_o | 26 +----------
scripts/link-vmlinux.sh | 5 +-
scripts/mksysmap | 6 +++
scripts/mod/file2alias.c | 34 ++++++++++++--
scripts/mod/modpost.c | 15 ++++++
scripts/mod/modpost.h | 2 +
12 files changed, 129 insertions(+), 78 deletions(-)
--
2.50.1
^ permalink raw reply
* [nf PATCH] netfilter: conntrack: helper: Replace -EEXIST by -EBUSY
From: Phil Sutter @ 2025-08-18 11:22 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, Yi Chen, linux-modules, netdev, Christophe Leroy
The helper registration return value is passed-through by module_init
callbacks which modprobe confuses with the harmless -EEXIST returned
when trying to load an already loaded module.
Make sure modprobe fails so users notice their helper has not been
registered and won't work.
Suggested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Fixes: 12f7a505331e ("netfilter: add user-space connection tracking helper infrastructure")
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
net/netfilter/nf_conntrack_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nf_conntrack_helper.c b/net/netfilter/nf_conntrack_helper.c
index 4ed5878cb25b..ceb48c3ca0a4 100644
--- a/net/netfilter/nf_conntrack_helper.c
+++ b/net/netfilter/nf_conntrack_helper.c
@@ -368,7 +368,7 @@ int nf_conntrack_helper_register(struct nf_conntrack_helper *me)
(cur->tuple.src.l3num == NFPROTO_UNSPEC ||
cur->tuple.src.l3num == me->tuple.src.l3num) &&
cur->tuple.dst.protonum == me->tuple.dst.protonum) {
- ret = -EEXIST;
+ ret = -EBUSY;
goto out;
}
}
@@ -379,7 +379,7 @@ int nf_conntrack_helper_register(struct nf_conntrack_helper *me)
hlist_for_each_entry(cur, &nf_ct_helper_hash[h], hnode) {
if (nf_ct_tuple_src_mask_cmp(&cur->tuple, &me->tuple,
&mask)) {
- ret = -EEXIST;
+ ret = -EBUSY;
goto out;
}
}
--
2.49.0
^ 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