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/[email protected]/ > > 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
