Re: [GIT PULL] asm-generic updates for 6.11

["Arnd Bergmann" <arnd@arndb.de>]

On Wed, Jul 17, 2024, at 06:02, Linus Torvalds wrote:
> On Mon, 15 Jul 2024 at 14:07, Arnd Bergmann <arnd@arndb.de> wrote:
>
> 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.

Right, I can confirm that this is not supposed to happen, and
it didn't do that for me during my testing. It should only
recreate asm/unistd_64.h if scripts/syscall.tbl changed,
as it does on the architectures that are using the
"archheaders:" rule to get into the architecture specific
arch/*/*/syscalls/Makefile/.

> 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.

I tried now both with my branch and with your latest commit
51835949dda3 ("Merge tag 'net-next-6.11' of
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next")
but can't reproduce it yet. My first guess was that this
might be related to building inside the source tree rather
than a separate object tree (which I used for my own testing),
but that did not make a difference either.

> 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.

I don't see those either (this is an x86 defconfig example):

$ find . -newer .config -name '*.h'
./include/generated/autoconf.h

So whatever caused the regression is probably a result of my
changes, but so far I haven't been able to explain or
reproduce it. I'll keep looking.

       Arnd