Re: [PATCH v10 0/2] module: Extend module_blacklist parameter to built-in modules

On Sun, Sep 06, 2026 at 11:56:04AM +0200, Arnd Bergmann wrote:

On Sun, Sep 6, 2026, at 02:28, Andrew Morton wrote:

quoted

On Fri, 4 Sep 2026 10:59:38 -0400 Aaron Tomlin [off-list ref] wrote:

quoted

In summary, this patch brings parity between modular and built-in drivers,
removes a pain point in boot-time disaster recovery, and provides users
with a predictable, consistent interface.

Really helpful, thanks.  Please add this to the [0/N] and maintain it.

I don't really know who are the potential audience for this change, nor
how to attract their attention.  Greg might have some insights but he
wasn't cc'ed.

Let's leave it a week to see if there's feedback then resend with these
adjustments?

FWIW, I previously asked the same question on this series
and still don't find the explanation lacking. Obviously,
consistency is good, but the added complexity doesn't feel
worth it here, given that this still has most of the same
problems as the existing "initcall_blacklist=" option [1].

I think patch 2/2 would be fine on its own, but for 1/2
I have yet to see a single example of a real-world problem
that could have been solved by this but not using
initcall_blacklist. In distro kernels, almost everything
is already a loadable module, while users with custom
kernels could easily turn off the drivers they don't want
or disable the initcall by name.

      Arnd

[1] https://lore.kernel.org/all/78ec1da5-11ae-4c35-a08e-cc88a5d083f4@app.fastmail.com/ (local)

Hi Arnd,

I understand your skepticism.

Let me provide more concrete context on the operational realities and why
initcall_blacklist= does not solve this for users.

First, regarding dependencies and undefined behavior, module_blacklist= is
indeed not intended as a day-to-day configuration knob, but as a boot-time
emergency recovery and triage tool. In terms of dependencies, built-in
drivers face the exact same behavior as modular drivers: if a blacklisted
driver provides resources to other drivers, those dependents fail their
probe or defer cleanly via -EPROBE_DEFER. The Linux driver model handles
missing devices without crashing the kernel. Moreover, this mechanism is
strictly restricted to drivers using module_init(), leaving core kernel
subsystems (e.g., sched and memory) completely untouched.

Second, regarding why initcall_blacklist= is impractical for users:

    1.  Obscure and unstable symbols

        initcall_blacklist= requires the exact internal C function name of
        the initcall (e.g., crypto_cmac_module_init). Typically,
        administrators and users know the module name, not internal C
        symbols. Furthermore, these function names are not stable and
        frequently change across kernel changes.

    2.  Mangled Names in Rust

        For drivers written in Rust, initcall symbols are compiler-mangled,
        which makes initcall_blacklist= virtually impossible for a user to
        specify at a boot prompt.

Consider a hardened appliance built with CONFIG_MODULES=n.
Should a kernel update introduce a panic in a built-in driver, the
administrator currently has no means of circumventing that driver using its
documented module name. They are consequently compelled either to
cross-compile a bespoke kernel on an auxiliary machine or to recover the
system via external media. Extending module_blacklist= enables them to
suppress the offending driver directly at the bootloader prompt, thereby
reaching an emergency shell to gather logs and triage the fault.

Andrew Morton suggested incorporating this detailed rationale into the
cover letter and looping in Greg Kroah-Hartman for driver-core perspective,
which I plan to do for the next revision.

I hope this helps.

Kind regards,
-- 
Aaron Tomlin