* 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
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