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 series extends the blacklisting functionality to
built-in modules by intercepting their initialisation routines during early
boot.

Following review feedback, the implementation has been split into two
separate changes to decouple the introduction of the new feature from the
terminology renaming:

    1.  The first patch extends the "module_blacklist=" parameter to
        built-in modules using the original blacklist terminology. It
        introduces the ".initcall.modnames" section to map initcall
        function pointers to their associated KBUILD_MODNAME strings
        (restricted only to module_init() invocations to save memory and
        avoid matching core kernel subsystems). It also restricts the check
        to a boot-time __init wrapper to eliminate Use-After-Free (UAF) and
        Spectre v1 vulnerability risks when loading dynamic modules at
        runtime, and adds a fast-path check to eliminate lookup overhead
        when the parameter is not in use

    2.  The second patch renames the variables and helper functions to
        adopt the preferred "module_denylist=" and module_is_denylisted()
        terminology in the codebase. To preserve the existing user-space
        ABI, "module_blacklist=" is kept as a legacy alias pointing to the
        same module_denylist variable

Changes since v9:

 - Enforced natural structure alignment on struct initcall_modname in
   include/linux/init.h via __aligned(__alignof__(struct initcall_modname))
   to prevent compiler over-alignment and inter-element linker padding
   (Petr Pavlu)

 - Removed STRUCT_ALIGN() before BOUNDED_SECTION_BY(.initcall.modnames,
   _initcall_modnames) to eliminate unnecessary alignment (Petr Pavlu)

 - Added <linux/init.h> to rust/bindings/bindings_helper.h and updated
   rust/macros/module.rs to use the generated
   ::kernel::bindings::initcall_modname struct rather than a locally
   defined type (Gary Guo and Petr Pavlu)

 - Placed the Rust module name string explicitly in .init.rodata within
   rust/macros/module.rs (#[link_section = ".init.rodata"]) so that the
   string memory is reclaimed alongside the initcall table after boot,
   matching the C implementation (Petr Pavlu)

 - Link to v9: https://lore.kernel.org/lkml/20260807012601.360452-1-atomlin@atomlin.com/

Changes since v8:

 - Extended Rust procedural macro support in rust/macros/module.rs to
   generate .initcall.modnames metadata for built-in Rust modules,
   maintaining feature parity with C built-in modules when evaluating
   "module_blacklist=" and "module_denylist=" (Petr Pavlu)

 - Merged the intermediate ___define_initcall_modname macro directly into
   __define_initcall_modname in include/linux/init.h to clean up macro
   expansion (Petr Pavlu)

 - Reverted the parameter name in module_init(x) back to 'x' in
   include/linux/module.h to remain consistent with surrounding comments
   (Petr Pavlu)

 - Cleaned up whitespace formatting in kernel/module/main.c (Petr Pavlu)

 - Link to v8: https://lore.kernel.org/lkml/20260724024744.616286-1-atomlin@atomlin.com/

Changes since v7:

 - Fixed a double evaluation of __initcall_id(fn) in the built-in module
   initcall macro expansion

 - Link to v7: https://lore.kernel.org/lkml/20260724014345.589326-1-atomlin@atomlin.com/

Changes since v6:

 - Grouped the __initcall_fn_ptr() macro definition inside the existing
   CONFIG_HAVE_ARCH_PREL32_RELOCATIONS block in include/linux/init.h
   (Petr Pavlu)

 - Localised the built-in module initcall level and section naming strictly
   to include/linux/init.h by introducing the macros
   __define_initcall_modname() and __builtin_module_initcall(), keeping
   include/linux/module.h clean (Petr Pavlu)

 - Removed the unnecessary dereference_function_descriptor() lookup wrapper
   in get_builtin_modname() in favour of a direct pointer comparison
   (Petr Pavlu)

 - Cleaned up whitespace formatting in kernel/module/main.c (Petr Pavlu)

 - Link to v6: https://lore.kernel.org/lkml/20260718190121.378314-1-atomlin@atomlin.com/

Changes since v5:

 - Resolved a modpost cross-section mismatch warning by introducing
   do_one_initcall_builtin() as a strict __init wrapper function, rather
   than performing the built-in module checks inside the __init_or_module
   do_one_initcall() function

 - Addressed a UAF race condition with concurrent dynamic module loading by
   strictly bounding the blacklist evaluation to early boot via the new
   __init wrapper, removing temporal check

 - Mitigated a potential Spectre v1 speculative execution vulnerability by
   ensuring get_builtin_modname() is exclusively called by __init code,
   preventing unprivileged runtime module loading from speculatively
   jumping into reclaimed ".init.text" instructions

 - Updated Documentation/admin-guide/kernel-parameters.txt to explicitly
   mark "module_blacklist=" as deprecated and document "module_denylist="

 - Link to v5: https://lore.kernel.org/lkml/20260718051350.344772-1-atomlin@atomlin.com/

Changes since v4:

 - Split the monolithic patch into two distinct commits. One to extend the
   functionality to built-in modules, and a second to safely transition the
   internal terminology to "denylist" (Arnd Bergmann)

 - Preserved "module_blacklist=" as a legacy core_param alias in the second
   commit to ensure backwards compatibility with existing userspace
   configurations

 - Restricted the population of the ".initcall.modnames" section strictly
   to module_init() rather than all ___define_initcall() invocations. This
   prevents non-module core initcalls from being redundantly mapped, saving
   memory and avoiding false-positive matches (Petr Pavlu)

 - Introduced a fast-path evaluation to check if the blacklist/denylist is
   actually populated before invoking get_builtin_modname(), avoiding
   unnecessary lookups during boot (Petr Pavlu)

 - Link to v4: https://lore.kernel.org/lkml/20260708020007.55728-1-atomlin@atomlin.com/

Changes since v3:

 - Renamed the external function prototype and internal helper to
   module_is_denylisted(), while updating the backing variable in
   main.c to module_denylist. To preserve user-space compatibility
   while adopting modern terminology, separate core_param entries have
   been introduced, allowing both the preferred module_denylist=
   parameter and the legacy module_blacklist= parameter to resolve to
   the same underlying variable (Andrew Morton)

 - I introduced the __initcall_fn_ptr() macro helper to dynamically
   resolve the initcall pointer configuration:
    - For architectures with relative 32-bit relocations
      (CONFIG_HAVE_ARCH_PREL32_RELOCATIONS=y), it resolves to the
      relocation stub pointer  __initcall_stub(fn, __iid, id)
    - For architectures without PREL32 relocations, it resolves
      directly to the function pointer fn

 - Decoupled the module_denylist parameter parsing and the
   module_is_denylisted() function from CONFIG_MODULES, moving the
   logic to init/main.c. This ensures the denylist works for built-in
   modules even on monolithic kernels built without loadable module
   support (CONFIG_MODULES=n)

 - Removed the conditional stub implementation of
   module_is_denylisted() in module.h and replaced it with a single,
   unconditional declaration outside of the #ifdef CONFIG_MODULES block.
   This prevents compiler warnings about missing prototypes and ensures
   visibility under a monolithic configuration

 - Replaced the initmem_freed state variable and its synchronisation
   logic in kernel_init() with race-free spatial boundary checks using
   is_kernel_text() and is_kernel_inittext() in initcall_get_modname()

 - Aligned the .initcall_modnames table with relocations by assigning
   .initcall_fn using the __initcall_stub() helper in
   ___define_initcall(). This ensures the lookup matches the actual stub
   pointer passed to do_one_initcall() when
   CONFIG_HAVE_ARCH_PREL32_RELOCATIONS is enabled. Passed the preprocessor
   __iid argument to ____define_initcall_modname once to avoid double
   evaluation of __COUNTER__ (which caused build failures with LTO)

 - Updated initcall_get_modname() in main.c to resolve the function
   pointer fn using dereference_function_descriptor(fn) prior to
   checking the .text and .init.text boundaries, and dereference both
   fn and p->initcall_fn in the comparison loop to support descriptor-based
   architectures (e.g., PPC64)

 - Link to v3: https://lore.kernel.org/lkml/20260706050337.7613-1-atomlin@atomlin.com/

Changes since v2:

 - Avoided relative 32-bit offsets (PREL32) with inline assembly, opting
   instead for standard C structures with absolute pointers. This fixes LTO
   and CFI compatibility issues (e.g., under Clang) where raw inline assembly
   fails to track compiler-generated symbols and CFI stubs

 - Placed module name strings into the ".init.rodata" section via a dedicated
   static array to ensure they are freed from memory after boot

 - Avoided Use-After-Free (UAF) bugs post-boot when loading dynamic modules:
   - Added an 'initmem_freed' flag, marked as '__ro_after_init', set after
     free_initmem() to skip table lookups for dynamically loaded modules
   - Added a blacklist check in do_init_module() for dynamic modules

 - Simplified the linker script using the BOUNDED_SECTION_PRE_LABEL() macro
   to define the ".initcall.modnames" section boundary

 - Added a dummy/stub implementation of module_is_blacklisted() when
   CONFIG_MODULES is disabled to avoid build errors

 - Link to v2: https://lore.kernel.org/lkml/20260622140259.2974-1-atomlin@atomlin.com/

Changes since v1:

 - Pivoted entirely from exposing built-in initcalls and their blacklist
   status via a debugfs interface to directly extending the existing
   "module_blacklist=" and new "module_blacklist=" to intercept built-in
   modules at boot (Petr Pavlu)

 - Implemented 32-bit relative offsets (CONFIG_HAVE_ARCH_PREL32_RELOCATIONS)
   to store the mappings, preventing binary bloat and preserving KASLR
   efficacy

 - Link to v1: https://lore.kernel.org/lkml/20260510061301.41341-1-atomlin@atomlin.com/

Aaron Tomlin (2):
  module: Extend module_blacklist parameter to built-in modules
  module: Rename module_blacklist to module_denylist

 .../admin-guide/kernel-parameters.txt         |  6 +-
 include/asm-generic/vmlinux.lds.h             |  3 +-
 include/linux/init.h                          | 25 ++++++++-
 include/linux/module.h                        |  4 +-
 init/main.c                                   | 55 ++++++++++++++++++-
 kernel/module/main.c                          | 25 +--------
 rust/bindings/bindings_helper.h               |  1 +
 rust/macros/module.rs                         | 17 ++++++
 8 files changed, 107 insertions(+), 29 deletions(-)

-- 
2.55.0

On Thu,  3 Sep 2026 14:55:55 -0400 Aaron Tomlin <atomlin@atomlin.com> 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 series extends the blacklisting functionality to
> built-in modules by intercepting their initialisation routines during early
> boot.

Why?  What are the use-cases and what is the value of this change
to our users?

Important, so please don't skimp on the details.

On Thu, Sep 03, 2026 at 01:29:24PM -0700, Andrew Morton wrote:
> On Thu,  3 Sep 2026 14:55:55 -0400 Aaron Tomlin <atomlin@atomlin.com> 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 series extends the blacklisting functionality to
> > built-in modules by intercepting their initialisation routines during early
> > boot.
> 
> Why?  What are the use-cases and what is the value of this change
> to our users?
> 
> Important, so please don't skimp on the details.

Hi Andrew,

Thanks for asking.

Here is the rationale, concrete use cases, and the value this hopefully
brings to users and administrators.

1.  The Core Problem and User Experience Gap
============================================

Today, module_blacklist= works strictly on loadable modules. When a user or
system administrator encounters a driver bug, hang during device probe, or
hardware fault during boot, the natural and widely documented remedy is to
pass module_blacklist=[driver] via the bootloader (GRUB, systemd-boot,
etc.).

However, if that driver is built into the kernel, the parameter is silently
ignored. The kernel proceeds to run the driver's initialisation routine
anyway, leading to the same panic, hang, or hardware misbehaviour.

From the user's standpoint, whether a driver was packaged by their
distribution or built by their provider as =m or =y is an internal
implementation detail. Having module_blacklist= silently fail solely based
on compilation configuration violates the principle of least surprise and
complicates system recovery.

2.  Why initcall_blacklist= is not an adequate substitute
=========================================================

The kernel does provide initcall_blacklist=, but it is impractical for
general users, sysadmins, and automated fleet management tools for several
reasons:

    Obscure symbol names

        - initcall_blacklist= requires the exact function name of the
          initcall (e.g., snb_pci_uarch_init and e1000_init_module). Users
          typically know the module name, not the internal function name.

    Internal instability

        - Initcall function names are internal kernel implementation
          details. They change across kernel releases, refactors, or macro
          rewrites, making it impossible to write stable bootloader
          configurations or recovery documentation across multiple kernel
          versions.

    Mangled names (Rust)

        - For modern drivers written in Rust, the initcall symbol names are
          compiler-mangled symbols (e.g. "_RNvX"), making
          initcall_blacklist= practically impossible for a human user to
          specify manually at a boot prompt.

module_blacklist= (or module_denylist=) resolves this by allowing users to
specify the canonical, user-facing module name (KBUILD_MODNAME) that they
already know.

3.  Concrete use cases
======================

    A.  Disaster recovery and triage on production systems

        When a kernel update introduces a regression in a built-in driver
        (e.g., a storage controller), administrators need a way to bypass
        that driver at boot time to get the system into a usable emergency
        shell or collect diagnostic logs, without having to rebuild the
        kernel on another machine.

    B.  Monolithic/Hardened environments (CONFIG_MODULES=n)

        In security-sensitive environments, kernels are frequently compiled
        without loadable module support (CONFIG_MODULES=n) to eliminate
        module loading attack vectors. On these systems, all drivers are
        built-in. If a hardware erratum or firmware bug triggers a hang in
        a built-in driver, administrators previously had no
        module-name-based mechanism to disable the offending driver.

    C. Hardware Errata and Conflicting Devices
       On systems with buggy firmware or conflicting device IDs where two drivers
       attempt to bind to the same hardware, users can prevent the conflicting
       built-in driver from initializing without patching and recompiling the
       entire kernel image.

4. Implementation and Overhead Considerations
=============================================

We took great care to ensure this change introduces virtually zero runtime
overhead:

    Scoped to module_init():
   
        - Only built-in drivers that explicitly use module_init() are
          tracked. Core kernel subsystems using core_initcall(),
          subsys_initcall(), etc. are unaffected.

    Zero Resident Memory:
   
        - The metadata table (.initcall.modnames) and the module name
          strings (.init.rodata) are placed entirely in init sections and
          are completely freed from memory after boot via free_initmem().

    Fast Path:
   
        - During boot, if neither module_blacklist= nor module_denylist=
          was supplied on the kernel command line, the lookup is bypassed
          entirely.


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.

Thanks,
--
Aaron Tomlin

On Fri, 4 Sep 2026 10:59:38 -0400 Aaron Tomlin <atomlin@atomlin.com> wrote:

> On Thu, Sep 03, 2026 at 01:29:24PM -0700, Andrew Morton wrote:
> > On Thu,  3 Sep 2026 14:55:55 -0400 Aaron Tomlin <atomlin@atomlin.com> 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 series extends the blacklisting functionality to
> > > built-in modules by intercepting their initialisation routines during early
> > > boot.
> > 
> > Why?  What are the use-cases and what is the value of this change
> > to our users?
> > 
> > Important, so please don't skimp on the details.
> 
> Hi Andrew,
> 
> Thanks for asking.
> 
> Here is the rationale, concrete use cases, and the value this hopefully
> brings to users and administrators.
>
> ...
>
> 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?

On Sat, Sep 05, 2026 at 05:28:17PM -0700, Andrew Morton wrote:
> On Fri, 4 Sep 2026 10:59:38 -0400 Aaron Tomlin <atomlin@atomlin.com> wrote:
> 
> > On Thu, Sep 03, 2026 at 01:29:24PM -0700, Andrew Morton wrote:
> > > On Thu,  3 Sep 2026 14:55:55 -0400 Aaron Tomlin <atomlin@atomlin.com> 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 series extends the blacklisting functionality to
> > > > built-in modules by intercepting their initialisation routines during early
> > > > boot.
> > > 
> > > Why?  What are the use-cases and what is the value of this change
> > > to our users?
> > > 
> > > Important, so please don't skimp on the details.
> > 
> > Hi Andrew,
> > 
> > Thanks for asking.
> > 
> > Here is the rationale, concrete use cases, and the value this hopefully
> > brings to users and administrators.
> >
> > ...
> >
> > 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?
> 

Hi Andrew,

Sounds like a great plan.

I will incorporate the rationale, use cases, and value proposition into the
cover letter and keep it maintained across future revisions.

I will also make sure Greg Kroah-Hartman is CC'd on the next iteration.

Waiting a week gives us good time to collect any further input.
When resending, I will also incorporate a few other refinements raised
during review i.e., a prerequisite fix to treat hyphens and underscores
interchangeably via parameqn() and as well as a Rust specific issue and
linker alignment cleanups [1]).

Petr and Gary, when you have a moment, please let me know your thoughts on [1].

[1]: https://lore.kernel.org/sashiko-reviews/xuj6okhlofl4cboopwjzqe3jyfmaxgvdpf5a3ek7bubew4vcbk@nkfqgoe53533/

Kind regards,
-- 
Aaron Tomlin

On Sun, Sep 6, 2026, at 02:28, Andrew Morton wrote:
> On Fri, 4 Sep 2026 10:59:38 -0400 Aaron Tomlin <atomlin@atomlin.com> wrote:
>>
>> 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/

On Sun, Sep 06, 2026 at 11:56:04AM +0200, Arnd Bergmann wrote:
> On Sun, Sep 6, 2026, at 02:28, Andrew Morton wrote:
> > On Fri, 4 Sep 2026 10:59:38 -0400 Aaron Tomlin <atomlin@atomlin.com> wrote:
> >>
> >> 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/

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

On Sun, Sep 06, 2026 at 10:08:57AM -0400, Aaron Tomlin wrote:
>     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.

Are you sure?

As far as I can tell, the Rust module! macro applies #[no_mangle] to the
initcall, so no mangling should apply to it. Its name is the name of the
module followed by an underscore.

Alice

On Wed, Sep 09, 2026 at 01:22:49PM +0000, Alice Ryhl wrote:
> On Sun, Sep 06, 2026 at 10:08:57AM -0400, Aaron Tomlin wrote:
> >     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.
> 
> Are you sure?
> 
> As far as I can tell, the Rust module! macro applies #[no_mangle] to the
> initcall, so no mangling should apply to it. Its name is the name of the
> module followed by an underscore.
> 
> Alice

Hi Alice,

Sorry, I was wrong.

Looking at rust/kernel/module.rs, indeed #[no_mangle] ensures the symbols
are named __{module_name}_init and __{module_name}_exit without compiler
mangling.

Thank you for the follow up!

Kind regards,
-- 
Aaron Tomlin

On Sun Sep 6, 2026 at 10:56 AM BST, Arnd Bergmann wrote:
> On Sun, Sep 6, 2026, at 02:28, Andrew Morton wrote:
>> On Fri, 4 Sep 2026 10:59:38 -0400 Aaron Tomlin <atomlin@atomlin.com> wrote:
>>>
>>> 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].

Yeah, I like the better consistency, which is why I propose unifying handling
for both built-in modules and loadable ones in
https://lore.kernel.org/all/DKNWEO3BOUOL.9COZBXZIGS6A@garyguo.net/.

IMO if we can unify them, then we get something that is both consistent and
*less* complexity.

The current solution makes thing more complex with only apparent consistency
(i.e. user observe the consistency from kernel parameter, but the internal
handling are two separate mechanisms), which should require a very strong reason
to pursue.

Best,
Gary

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