On Thu, Jun 25, 2026 at 04:50:11PM -0700, Andrew Morton wrote: > On Sun, 10 May 2026 02:13:01 -0400 Aaron Tomlin <[email protected]> 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/[email protected]/ Kind regards, -- Aaron Tomlin
