On Wed, Jun 17, 2026 at 02:39:53PM +0200, Petr Pavlu wrote:
> On 5/10/26 8:13 AM, Aaron Tomlin 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.
>
> My understanding is that initcall_blacklist is primarily a debugging
> facility. This is documented in
> Documentation/admin-guide/kernel-parameters.txt [1] and also outlined in
> the initial commit 7b0b73d76651 ("init/main.c: add initcall_blacklist
> kernel parameter") [2]. It is expected that to use it, one must inspect
> the kernel source code.
>
> If the goal is to allow specific built-in modules to be blacklisted,
> I wonder whether extending module_blacklist to also cover built-in
> modules might be a better option. Module names are more appropriate for
> administrators to use, while initcall names should remain internal to
> the kernel. Additionally, initcalls are typically "static" and therefore
> are not guaranteed to have unique names + using module names avoids
> a dependency on CONFIG_KALLSYMS=y.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt?h=v7.1#n2408
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b0b73d76651e5f88c88b76efa18d719f832bf6fHi Petr, Thank you for your review and the excellent historical context. Your points regarding static function name collisions and the unnecessary kallsyms dependency are correct. Extending the module blacklist parameter to intercept built in modules makes far more architectural sense. It provides a consistent interface for administrators and aligns perfectly with existing kernel conventions. For the forthcoming v2 patchset, I have completely dropped the original approach. Instead, I am implementing a parallel metadata section. By updating the core initcall macros, the compiler will emit the module name string into a custom ELF section directly alongside the function pointer. The core boot code can then evaluate this mapping against the module blacklist before executing the initialisation function. This new architecture performs all the mapping at compile time. It entirely avoids the kallsyms dependency you highlighted, perfectly preserves the original function names for debugging purposes, and resides securely within the initialisation data so the memory is freed completely immediately after boot. Kind regards, -- Aaron Tomlin
signature.asc
Description: PGP signature
