Re: [PATCH v2 0/2] kbuild: Give jobserver-exec recipes the jobserver

[Nathan Chancellor]

On Sat, Oct 10, 2026 at 01:19:09AM -0700, Kees Cook wrote:
> Hi!
> 
> Paul reported a build failure on CentOS Stream 9 with linux-next[1]: the
> kernel builds, but scripts/jobserver-exec prints
> 
>   WARNING: Unable to reopen jobserver read-side pipe: FileNotFoundError(2, 'No such file or directory')
> 
> and rcutorture's build check counts the "Error" in that line. CentOS's
> make 4.3 carries a backport of the fix for GNU Make bug 58232, so
> sub-makes, like the top-level make, give the jobserver pipe only to
> recipes marked recursive, while MAKEFLAGS still names it. The new pigz
> steps (1/2), for the kernel image, the built-in initramfs, and the other
> gzip rules, and the older Clang LTO initcall ordering step (2/2) run
> jobserver-exec from recipes without "+", so pigz gets one thread and the
> initcall script caps its children at the CPU count instead of the free
> job slots. Mark these recipes recursive, as was done for rustc.
> 
> Thanks!
> 
> -Kees
> 
>  v2:
>  - 1/2: also mark the gzip rules that choose gzip through a variable,
>    including the built-in initramfs in usr/Makefile, which rcutorture's
>    kvm.sh builds and v1 missed (Paul)
>  - 1/2: update the gzip entry in Documentation/kbuild/makefiles.rst
>    (Nicolas)
>  - 2/2: cite Masahiro's earlier version of this change and say when the
>    script gets more than one archive (Nicolas)
>  - v1..v2 diff: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/diff/?id=dev/next-20261001/pigz-recursive/v2&id2=dev/next-20261001/pigz-recursive/v1
>  v1: https://lore.kernel.org/all/20261009062722.i.253-kees@xxxxxxxxxx/
> 
> [1] https://lore.kernel.org/all/0ddb5e5e-f801-444c-aa98-0cfe814a3026@paulmck-laptop/
> 
> Kees Cook (2):
>   kbuild: Mark the gzip recipes as recursive
>   kbuild: Mark the initcall ordering recipe as recursive

I've kicked these into -next, I will formally apply them to
kbuild-next-speedups once Paul can confirm that it resolves his
regression. Thanks a lot for the assist here!

-- 
Cheers,
Nathan