Re: [PATCH v4] module: Extend module_blacklist parameter to built-in modules

[Aaron Tomlin]

On Mon, Jul 13, 2026 at 06:02:04PM +0200, Petr Pavlu wrote:
> > To address your concern regarding undefined behaviour, disabling a built-in
> > driver carries the exact same dependency risks as preventing a loadable
> > module from loading via the traditional blacklist. In both scenarios,
> > dependent drivers will naturally fail to probe or initialise. System
> > administrators who apply denylists are already expected to understand the
> > hardware and software dependencies of the modules they are explicitly
> > disabling.
> 
> The dependency risk is somewhat greater with built-in modules. Consider
> two modules, A and B. Module A exports fun_a() that is used by module B.
> fun_a() depends on state initialized in A's init function.
> 
> If both modules are loadable, then B can be inserted only after A has
> been loaded successfully, that is, A is not blacklisted and its init
> function completes successfully.
> 
> If A is built-in and blacklisted, nothing prevents B from calling
> fun_a() and potentially encountering an undefined state.
> 
> That said, it seems the same problem can already occur today if A is
> built-in and fails to initialize, since do_initcall_level() doesn't
> check the return value from do_one_initcall().
> 
> > 
> > I understand your hesitation regarding added complexity. However, with the
> > fast-path optimisation suggested by Sami (which bypassing the scan entirely
> > if the parameter is unused), the overhead is essentially zero. I believe
> > bridging the logical gap between how we treat =m and =y modules is well
> > worth that minimal footprint.
> 
> I see the point from a consistency perspective.

Hi Petr,

Thank you for your insights; you raise two excellent points.

Regarding the policy gap with /etc/modprobe.d/, you are entirely correct.
However, this discrepancy reinforces the reality that module_blacklist= via
the kernel command line is the only single, deterministic location where an
administrator can declare configuration policy that spans early boot before
the root filesystem is mounted. Making this specific interface robust
against both =m and =y configurations is therefore paramount for enterprise
consistency.

Yes, while a blacklisted built-in module A could theoretically leave
dependent module B calling an uninitialised state via fun_a(), your
observation that this already occurs today when a built-in module's
initcall simply fails runtime initialisation completely refutes the idea
that this patch introduces a novel class of undefined behaviour. The kernel
already tolerates this exact condition because do_initcall_level()
purposefully does not track or act upon the return values of
do_one_initcall().

Given that the architectural risk is identical to existing failure modes,
bringing behavioral consistency to the user-facing administrative interface
seems a clear net benefit.

Kind regards,
-- 
Aaron Tomlin