Re: [PATCH v1 2/2] kbuild: Mark the initcall ordering recipe as recursive

[Nicolas Schier]

> generate_initcall_order.pl, which orders initcalls for Clang LTO, forks
> a child per input file, up to the job count scripts/jobserver-exec
> passes it in PARALLELISM. It used to run from link-vmlinux.sh, which
> the top-level Makefile invokes as a recursive recipe, but
> commit 5d45950dfbb15 ("kbuild: move vmlinux.o link to
> scripts/Makefile.vmlinux_o") moved it into a recipe without "+".
> 
> GNU Make passes the jobserver pipe only to recipes it treats as
> recursive, and the make 4.3 in CentOS Stream 9 also hides it in
> sub-makes (a backport of the fix for GNU Make bug 58232), so
> jobserver-exec cannot open it and prints:
> 
>   WARNING: Unable to reopen jobserver read-side pipe: FileNotFoundError(2, 'No such file or directory')
> 
> PARALLELISM is then left unset, and the script caps its children at the
> number of online CPUs instead of the free job slots.
> 
> Mark the recipe as recursive again.
> 
> Tested ARCH=x86_64 defconfig with CONFIG_LTO_CLANG_THIN=y, LLVM=1
> (Clang 24.0.0git), and GNU Make 4.3 plus CentOS Stream 9's
> make-4.3-cloexec.patch.
> 
> Fixes: 5d45950dfbb15 ("kbuild: move vmlinux.o link to scripts/Makefile.vmlinux_o")
> Assisted-by: LLM
> Signed-off-by: Kees Cook <kees@xxxxxxxxxx>
> ---
>  scripts/Makefile.vmlinux_o | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/Makefile.vmlinux_o b/scripts/Makefile.vmlinux_o
> index 24a3a4fd271c..0b37bd5dc3a4 100644
> --- a/scripts/Makefile.vmlinux_o
> +++ b/scripts/Makefile.vmlinux_o
> @@ -19,7 +19,7 @@ quiet_cmd_gen_initcalls_lds = GEN     $@
>  
>  .tmp_initcalls.lds: $(srctree)/scripts/generate_initcall_order.pl \
>  		vmlinux.a $(KBUILD_VMLINUX_LIBS) FORCE
> -	$(call if_changed,gen_initcalls_lds)
> +	+$(call if_changed,gen_initcalls_lds)

b4 hinted me on [1], where a similar fix was rejected; but as we know
have more arguments to generate_initcall_order.pl
($(KBUILD_VMLINUX_LIBS)), the situation is slightly different.

Thanks!

Reviewed-by: Nicolas Schier <n.schier@xxxxxxxxx>


[1]: https://lore.kernel.org/all/CAK7LNARCM=rUm8mA8GRQ7ufeyfneGf4OEvHmESKt=zuxs2KrHw@xxxxxxxxxxxxxx/

-- 
Nicolas