Re: [PATCH v7 1/2] module: Extend module_blacklist parameter to built-in modules

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [Low] Double evaluation of `__initcall_id(fn)` within `__define_initcall_=
modname` causes a fatal compilation/linker error when `CONFIG_HAVE_ARCH_PRE=
L32_RELOCATIONS` is enabled.
--

--- Patch [1]: [PATCH v7 1/2] module: Extend module_blacklist parameter to =
built-in modules ---
commit e69e6c4b3390b09453c5912322a9c34ef99cf6b5
Author: Aaron Tomlin <[email protected]>

module: Extend module_blacklist parameter to built-in modules

This commit extends the "module_blacklist=3D" command-line parameter to
intercept built-in modules during early boot. It introduces the
".initcall.modnames" section to map initcalls to module names, checking
this metadata before executing built-in initcalls.

> diff --git a/include/linux/init.h b/include/linux/init.h
> index 40331923b9f4a..46141c263ef25 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -252,6 +252,7 @@ extern struct module __this_module;
>  #endif
> =20
>  #ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
> +#define __initcall_fn_ptr(fn, id)	__initcall_stub(fn, __initcall_id(fn),=
 id)
>  #define ____define_initcall(fn, __stub, __name, __sec)		\
>  	__define_initcall_stub(__stub, fn)			\
>  	asm(".section	\"" __sec "\", \"a\"		\n"	\
[ ... ]
> @@ -271,7 +273,24 @@ extern struct module __this_module;
>  		__initcall_name(initcall, __iid, id),		\
>  		__initcall_section(__sec, __iid))
> =20
> -#define ___define_initcall(fn, id, __sec)			\
> +struct initcall_modname {
> +	initcall_t initcall_fn;
> +	const char *modname;
> +};
> +
> +#define __define_initcall_modname(fn, id)				\
> +	__define_initcall(fn, id)					\
> +	static const char __initstr_##fn[] __used __aligned(1)		\
> +		__section(".init.rodata") =3D KBUILD_MODNAME;		\
> +	static const struct initcall_modname __modname_##fn __used	\
> +		__section(".initcall.modnames") =3D {			\
> +			.initcall_fn =3D __initcall_fn_ptr(fn, id),	\
> +			.modname =3D __initstr_##fn			\
> +		};

[Severity: Low]
Does this double evaluation of __initcall_id(fn) break the build when
CONFIG_HAVE_ARCH_PREL32_RELOCATIONS is enabled?

__define_initcall(fn, id) evaluates __initcall_id(fn) as part of its expans=
ion.
__initcall_fn_ptr(fn, id) also evaluates __initcall_id(fn).

Since __initcall_id() relies on the __COUNTER__ preprocessor directive,
these two evaluations will consume different counter values. Could this
generate mismatched stub references, causing undefined reference errors
during the build for built-in modules?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260724014345.5893=
[email protected]?part=3D1