Re: [PATCH] init/main: Expose built-in initcalls and blacklist status via debugfs

[Aaron Tomlin]

On Thu, Jun 25, 2026 at 04:50:11PM -0700, Andrew Morton wrote:
> On Sun, 10 May 2026 02:13:01 -0400 Aaron Tomlin <atomlin@xxxxxxxxxxx> wrote:
> 
> > At present, identifying the correct function name to supply to the
> > "initcall_blacklist=" kernel command-line parameter requires manual
> > inspection of the source code or kernel symbol tables. Furthermore,
> > administrators lack a reliable runtime mechanism to verify whether a
> > specified built-in module has been successfully blacklisted.
> 
> I expect nobody has felt a need for this in their day-to-day work, so
> the interest is low.
> 
> A detailed description of the use-cases would be of benefit - help
> people better understand the value of this to our users.  I suggest you
> add this info and send a v2, if motivated.

Hi Andrew,

Thank you for taking the time to review the patch. I appreciate the
pragmatic feedback.

> > To resolve this, introduce a new debugfs interface at
> > /sys/kernel/debug/modules/builtin_initcalls. This file enumerates all
> > built-in modules alongside their corresponding initialisation callbacks
> > (e.g., those specified by module_init()) in a simple format:
> > "module_name init_callback".
> 
> Isn't this information all available at build time?
> 
> Can we extract it and put it in some file somewhere which becomes part
> of the distributed kernel package?

It is indeed possible to extract this. We currently generate
modules.builtin, but it only lists module paths, not the corresponding
initcall function names. While a userspace application could theoretically
parse System.map to find these relationships, this approach assumes the
presence of Linux kernel packages on the target server. In some
environments, these files are frequently stripped or omitted entirely.

> > If a built-in module has been actively
> > blacklisted, the entry is explicitly appended with a " [blacklisted]"
> > suffix.
> 
> Can this be added to the /proc/modules output in some fashion?  Perhaps
> just add TAINT_BLACKLISTED and we get this info almost for free?

Unfortunately, we cannot append this information to /proc/modules. That
interface iterates over the kernel's modules list, which relies on struct
module metadata. Because built-in modules are statically linked into
vmlinux, they lack this runtime structure entirely and are invisible to
/proc/modules.

Petr Pavlu offered excellent advice — extend module_blacklist to also
cover built-in modules [1] — I do like this idea.


[1]: https://lore.kernel.org/lkml/79ace94f-31d3-4a5e-9a47-3fad69304fe5@xxxxxxxx/

Kind regards,
-- 
Aaron Tomlin