On Fri, Jul 10, 2026 at 08:42:49AM -0700, Sami Tolvanen wrote: > Hi Aaron, > > On Tue, Jul 7, 2026 at 7:00 PM Aaron Tomlin <[email protected]> wrote: > > > > +static const char *initcall_get_modname(initcall_t fn) > > +{ > > + struct initcall_modname *p; > > + unsigned long addr = (unsigned > > long)dereference_function_descriptor(fn); > > + > > + if (system_state >= SYSTEM_FREEING_INITMEM) > > + return NULL; > > + > > + if (!is_kernel_text(addr) && > > + !is_kernel_inittext(addr)) > > + return NULL; > > + > > + for (p = __start_initcall_modnames; p < __stop_initcall_modnames; > > p++) { > > + if (dereference_function_descriptor(p->initcall_fn) == > > + dereference_function_descriptor(fn)) > > + return p->modname; > > + } > > + return NULL; > > +} > > + > > int __init_or_module do_one_initcall(initcall_t fn) > > { > > int count = preempt_count(); > > char msgbuf[64]; > > + const char *modname; > > int ret; > > > > + modname = initcall_get_modname(fn); > > If I'm reading this correctly, this ends up scanning the > initcall_modnames list for every initcall. Have you measured whether > this has any boot time impact? Can we at least skip this scan if no > module denylist is provided?
Hi Sami, Avoiding unnecessary overhead on the critical boot path is absolutely the right approach. I completely agree with your suggestion to bypass the scan when it is not needed. In the forthcoming iteration, I will introduce a fast-path check. Since the denylist parameter is strictly opt-in, we can simply evaluate whether module_denylist (or module_blacklist) has been populated before calling initcall_get_modname(). This was previously reiterated to Arnd here [1]. [1]: https://lore.kernel.org/lkml/ea7kdjwoucecvetzf73ce5dpda3l3etb6i75bks6deekfu6mb6@ooptba3x2oh3/ Kind regards, -- Aaron Tomlin
