* Re: [PATCH v2] rust: module_param: return value by copy from `value`
From: Petr Pavlu @ 2026-07-10 15:58 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Andreas Hindborg, Miguel Ojeda, Luis Chamberlain,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross,
Danilo Krummrich, linux-modules, linux-kernel, rust-for-linux
In-Reply-To: <alEBInX9gD1M5NAr@google.com>
On 7/10/26 4:26 PM, Alice Ryhl wrote:
> On Fri, Jul 10, 2026 at 10:13:53AM +0200, Petr Pavlu wrote:
>> On 7/9/26 4:13 PM, Miguel Ojeda wrote:
>>> On Thu, Jul 9, 2026 at 1:48 PM Petr Pavlu <petr.pavlu@suse.com> wrote:
>>>>
>>>> @Miguel, please let me know if I should take this patch on modules-next,
>>>> or if you'd prefer for it to go through the Rust tree.
>>>
>>> Please feel free to take it through modules-next, of course.
>>
>> Thanks for the confirmation. Queued now on modules-next for v7.3-rc1.
>
> I'm seeing this error on x86 with latest nightly rust compiler:
>
> rust/kernel.o: error: objtool: _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramaEB4_() falls through to next function _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramhEB4_()
> rust/kernel.o: error: objtool: _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramhEB4_() falls through to next function _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramiEB4_()
> rust/kernel.o: error: objtool: _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramiEB4_() falls through to next function _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramjEB4_()
> rust/kernel.o: error: objtool: _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramjEB4_() falls through to next function _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramlEB4_()
> rust/kernel.o: error: objtool: _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramlEB4_() falls through to next function _RINvNtCs65fqAZscXCv_6kernel12module_param9set_parammEB4_()
> rust/kernel.o: error: objtool: _RINvNtCs65fqAZscXCv_6kernel12module_param9set_parammEB4_() falls through to next function _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramsEB4_()
> rust/kernel.o: error: objtool: _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramsEB4_() falls through to next function _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramtEB4_()
> rust/kernel.o: error: objtool: _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramtEB4_() falls through to next function _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramyEB4_()
> rust/kernel.o: error: objtool: _RINvNtCs65fqAZscXCv_6kernel12module_param9set_paramyEB4_() falls through to next function _RINvNvNtCs65fqAZscXCv_6kernel6devres16register_foreign8callbackINtNtCsbtRzKR1rrUg_4core3pin3PinINtNtNtB6_5alloc4kbox3BoxNtNtNtB6_3pci3irq21IrqVectorRegistrationNtNtB1A_9allocator7KmallocEEEB6_()
> rust/kernel.o: error: objtool: _RNvMNtCs65fqAZscXCv_6kernel6deviceNtB2_6Device10get_device() falls through to next function _RNvMNtCs65fqAZscXCv_6kernel6devresINtB2_6DevresNtNtB4_3i2c12RegistrationE19devres_node_releaseB4_()
> rust/kernel.o: error: objtool: _RNvMNtCs65fqAZscXCv_6kernel6devresINtB2_6DevresNtNtB4_3i2c12RegistrationE19devres_node_releaseB4_() falls through to next function _RNvMNtCs65fqAZscXCv_6kernel6devresINtB2_6DevresNtNtB4_3i2c12RegistrationE21devres_node_free_nodeB4_()
>
> I understand this is probably due to a new function in Rust stdlib that
> is no_return, so probably not caused by this patch even if this is
> triggering it.
I can't immediately reproduce this issue. I tried with linux-next
(next-20260710), rustc 1.99.0-nightly (af3d95584 2026-07-09) and
x86_64_defconfig with Rust enabled. What am I missing? Could you send me
your config and the produced rust/kernel.o off-list?
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH v4] module: Extend module_blacklist parameter to built-in modules
From: Arnd Bergmann @ 2026-07-10 15:59 UTC (permalink / raw)
To: Aaron Tomlin, Luis Chamberlain, Petr Pavlu, da.gomez,
Sami Tolvanen, Peter Zijlstra
Cc: Andrew Morton, Masami Hiramatsu, neelx, da.anzani, sean, chjohnst,
steve, mproche, nick.lane, Linux-Arch, linux-modules,
linux-kernel
In-Reply-To: <20260708020007.55728-1-atomlin@atomlin.com>
On Wed, Jul 8, 2026, at 04:00, Aaron Tomlin wrote:
> Currently, the "module_blacklist=" command-line parameter only applies
> to loadable modules. If a module is built-in, the parameter is silently
> ignored. This patch extends the blacklisting functionality to built-in
> modules by intercepting their initialisation routines during early boot.
Andrew already asked you to provide more background on what you need
this part for. Do you have a specific driver you need to disable?
Can't you do the same thing using initcall_blacklist?
> To preserve the existing user-space ABI, "module_blacklist=" is kept
> as a legacy alias pointing to the same module_denylist variable.
It looks like the denylist is only introduced in the same patch?
That sounds more useful, but would better be done in a separate
change, and also needs a proper changelog text.
Arnd
^ permalink raw reply
* Re: [PATCH v2] rust: module_param: return value by copy from `value`
From: Miguel Ojeda @ 2026-07-10 17:00 UTC (permalink / raw)
To: Petr Pavlu
Cc: Alice Ryhl, Andreas Hindborg, Miguel Ojeda, Luis Chamberlain,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross,
Danilo Krummrich, linux-modules, linux-kernel, rust-for-linux
In-Reply-To: <bd1f78bc-51b4-44b7-8e3c-7accc9e173f2@suse.com>
On Fri, Jul 10, 2026 at 5:58 PM Petr Pavlu <petr.pavlu@suse.com> wrote:
>
> I can't immediately reproduce this issue. I tried with linux-next
> (next-20260710), rustc 1.99.0-nightly (af3d95584 2026-07-09) and
> x86_64_defconfig with Rust enabled. What am I missing? Could you send me
> your config and the produced rust/kernel.o off-list?
I can reproduce it independently of this patch.
It looks like `panic_null_reference_constructed`, added the other day
-- I will send the patch.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2] rust: module_param: return value by copy from `value`
From: Miguel Ojeda @ 2026-07-10 17:33 UTC (permalink / raw)
To: Petr Pavlu
Cc: Alice Ryhl, Andreas Hindborg, Miguel Ojeda, Luis Chamberlain,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross,
Danilo Krummrich, linux-modules, linux-kernel, rust-for-linux
In-Reply-To: <CANiq72nxK=nCf7C-GQ8JCtaTnOaDGwGDFKoQEVb4fqNonkKn3w@mail.gmail.com>
On Fri, Jul 10, 2026 at 7:00 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> It looks like `panic_null_reference_constructed`, added the other day
> -- I will send the patch.
https://lore.kernel.org/rust-for-linux/20260710173252.191781-1-ojeda@kernel.org/
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v4] module: Extend module_blacklist parameter to built-in modules
From: Aaron Tomlin @ 2026-07-10 23:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Luis Chamberlain, Petr Pavlu, da.gomez, Sami Tolvanen,
Peter Zijlstra, Andrew Morton, Masami Hiramatsu, neelx, da.anzani,
sean, chjohnst, steve, mproche, nick.lane, Linux-Arch,
linux-modules, linux-kernel
In-Reply-To: <33171ccd-038b-4bb8-b796-f104a131c0ee@app.fastmail.com>
On Fri, Jul 10, 2026 at 05:59:59PM +0200, Arnd Bergmann wrote:
> On Wed, Jul 8, 2026, at 04:00, Aaron Tomlin wrote:
> > Currently, the "module_blacklist=" command-line parameter only applies
> > to loadable modules. If a module is built-in, the parameter is silently
> > ignored. This patch extends the blacklisting functionality to built-in
> > modules by intercepting their initialisation routines during early boot.
>
> Andrew already asked you to provide more background on what you need
> this part for. Do you have a specific driver you need to disable?
>
> Can't you do the same thing using initcall_blacklist?
Hi Arnd,
Thank you for your feedback and for highlighting Andrew's request for
further context.
The primary motivation for this patch is to provide consistent
administrative control. From a system administrator's perspective, whether
a specific driver is configured as loadable or built-in is often an opaque,
distribution-level decision. If an administrator applies
module_blacklist=foo (or the modern module_denylist=foo) to disable a
problematic driver across a fleet of machines, they rightfully expect it to
be disabled. Currently, if a distribution later changes that module's
configuration from loadable to built-in, the boot parameter is silently
ignored. The driver will subsequently initialise, which can cause
unexpected operational regressions or security policy violations.
Regarding your suggestion to use initcall_blacklist=, while it is certainly
a capable mechanism, it is fundamentally considered a debugging facility
intended for developers. To utilise it, an administrator must know the
exact internal C function name of the driver's initialisation routine
(e.g., initcall_blacklist=foo_driver_init). This requires inspecting the
kernel source code and relies on internal symbols that are subject to
change between releases. Conversely, the module name itself provides a
stable, user-facing administrative interface.
Furthermore, I must credit Petr Pavlu, who offered excellent advice [1]
suggesting that extending module_blacklist= to encompass built-in modules
is the most logical and robust approach to solving this discrepancy.
[1] https://lore.kernel.org/lkml/79ace94f-31d3-4a5e-9a47-3fad69304fe5@suse.com/
> > To preserve the existing user-space ABI, "module_blacklist=" is kept
> > as a legacy alias pointing to the same module_denylist variable.
>
> It looks like the denylist is only introduced in the same patch?
Correct.
> That sounds more useful, but would better be done in a separate
> change, and also needs a proper changelog text.
Understood.
Kind regards,
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH v19 39/40] rust: completion: Add __rust_helper to rust_helper_wait_for_completion()
From: Miguel Ojeda @ 2026-07-11 12:13 UTC (permalink / raw)
To: Byungchul Park, Gary Guo
Cc: linux-kernel, max.byungchul.park, kernel_team, torvalds,
damien.lemoal, linux-ide, adilger.kernel, linux-ext4, mingo,
peterz, will, tglx, rostedt, joel, sashal, daniel.vetter,
duyuyang, johannes.berg, tj, tytso, willy, david, amir73il,
gregkh, kernel-team, linux-mm, akpm, mhocko, minchan, hannes,
vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes, vbabka,
ngupta, linux-block, josef, linux-fsdevel, jack, jlayton,
dan.j.williams, hch, djwong, dri-devel, rodrigosiqueiramelo,
melissa.srw, hamohammed.sa, harry.yoo, chris.p.wilson,
gwan-gyeong.mun, boqun.feng, longman, yunseong.kim, ysk,
yeoreum.yun, netdev, matthew.brost, her0gyugyu, corbet,
catalin.marinas, bp, x86, hpa, luto, sumit.semwal, gustavo,
christian.koenig, andi.shyti, arnd, lorenzo.stoakes, Liam.Howlett,
rppt, surenb, mcgrof, petr.pavlu, da.gomez, samitolvanen, paulmck,
frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy, anna, kees,
bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, neilb, bagasdotme, wsa+renesas, dave.hansen,
geert, ojeda, alex.gaynor, bjorn3_gh, lossin, a.hindborg,
aliceryhl, tmgross, rust-for-linux
In-Reply-To: <20260706061928.66713-40-byungchul@sk.com>
On Mon, Jul 6, 2026 at 8:22 AM Byungchul Park <byungchul@sk.com> wrote:
>
> This is needed to inline these helpers into Rust code, which is required
> for DEPT to play with wait_for_completion().
>
> Signed-off-by: Byungchul Park <byungchul@sk.com>
Apart from what Gary said -- why did you need to do this in a separate
patch in the same series?
Cheers,
Miguel
^ permalink raw reply
page: | 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