On Mon, 15 Jul 2024 at 14:07, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> Most of this is part of my ongoing work to clean up the system call
> tables. In this bit, all of the newer architectures are converted to
> use the machine readable syscall.tbl format instead in place of complex
> macros in include/uapi/asm-generic/unistd.h.
I haven't bisected things, but I think this code is seriously and
utterly broken.
When I do a
make allmodconfig
make -j199 > ../makes
on my arm64 machine, it keeps rebuilding pretty much the whole thing
every time - whether I have made any changes or not.
The second time it should be basically a no-op. Sure, a fairly slow
no-op, because 'make' will go through the motions and check all the
dependencies etc, but it shouldn't *build* anything.
But that's not at all what I see. It rebuilds pretty much the whole
tree (not quite everything, but at an estimate it rebuilds the
majority of files).
And the first things I see in the build log is
SYSHDR arch/arm64/include/generated/uapi/asm/unistd_64.h
SYSTBL arch/arm64/include/generated/asm/syscall_table_32.h
SYSTBL arch/arm64/include/generated/asm/syscall_table_64.h
SYSHDR arch/arm64/include/generated/asm/unistd_32.h
SYSHDR arch/arm64/include/generated/asm/unistd_compat_32.h
HDRINST usr/include/asm/unistd_64.h
CC arch/arm64/kernel/asm-offsets.s
CALL scripts/checksyscalls.sh
...
which is why I'm suspecting your changes without having actually
bisected the build time regression at all.
And yes, I checked - it does update the timestamps of those four
generated files: unistd_compat_32.h, unistd_32.h, syscall_table_64.h,
and syscall_table_32.h
Every time.
So I'm pretty sure it's on you, even if I didn't do the bisection.
This needs fixing, urgently. Because it turns a "small pull" into
always taking 5+ minutes for me. I didn't notice immediately, because
many of my core pulls I _expect_ to rebuild everything, but...
Btw, I don't see the same effect on x86-64, so this is purely an arm64
issue (well, and presumably any other architecture that uses
'syscall-y').
You might want to do a build like this:
make allmodconfig
make
twice, and then do
find . -newer .config -name '*.h'
to find things where the build has generated header files with new
timestamps despite no changes.
There are other bad cases, but the syscall ones seem to be the ones
that cause problems.
I'm adding Masahiro to the participants, because of some of the other
files that *do* show up for me when I do the above thing:
On x86:
arch/x86/boot/voffset.h
arch/x86/boot/zoffset.h
security/apparmor/net_names.h
On arm64 (ignoring the above and the syscall ones):
include/generated/vdso-offsets.h
That 'find' also shows that the install headers thing does the same to
the ./usr/include/ directories, but the kernel build doesn't care
about those.
Linus
