linux-kernel - Re: [GIT PULL] Driver core patches for 5.2-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wh=Uscp=yO1p===JjH3x9NS-ez+wrk64Z0pw7EGfWvVTA@mail.gmail.com>
Date:   Thu, 9 May 2019 13:47:54 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Greg KH <gregkh@...uxfoundation.org>,
        "Joel Fernandes (Google)" <joel@...lfernandes.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Driver core patches for 5.2-rc1

[ Ok, this may look irrelevant to people, but I actually notice this
because I do quick rebuilds *all* the time, so the 30s vs 41s
difference is actually something I reacted to and then tried to figure
out... ]

On Tue, May 7, 2019 at 10:59 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> Joel Fernandes (Google) (2):
>       Provide in-kernel headers to make extending kernel easier

Joel and Masahiro,
 this commit does annoying things. It's a small thing, but it ends up
grating on my kernel rebuild times, so I hope somebody can take a look
at it..

Try building a kernel with no changes, and it shouldn't re-link.

HOWEVER.

If you re-make the config in between, the kernel/kheaders_data.tar.xz
is re-generated too. I think it checks timestamps despite having that
"CHK" phase that should verify just contents.

I think the kernel/config_data.gz rules do the same thing, judging by
the output.

I use "make allmodconfig" to re-generate the same kernel config, which
triggers this. The difference between "nothing changed" and "rerun
'make allmodconfig' and nothing _still_ should have changed" is quite
stark:

- nothing changed: rebuild in less than 30s

    [torvalds@i7 linux]$ time make -j32
      DESCEND  objtool
      CALL    scripts/atomic/check-atomics.sh
      CALL    scripts/checksyscalls.sh
      CHK     include/generated/compile.h
      CHK     kernel/kheaders_data.tar.xz
      Building modules, stage 2.
    Kernel: arch/x86/boot/bzImage is ready  (#9)
      MODPOST 7282 modules

    real        0m29.379s
    user        1m50.586s
    sys 0m41.047s

- do (the same) "make allmodconfig" in between, now rebuild time is
just over 41s:

    [torvalds@i7 linux]$ make allmodconfig

    [torvalds@i7 linux]$ time make -j32
    scripts/kconfig/conf  --syncconfig Kconfig
      DESCEND  objtool
      CALL    scripts/atomic/check-atomics.sh
      CALL    scripts/checksyscalls.sh
      CHK     include/generated/compile.h
      GZIP    kernel/config_data.gz
      CHK     kernel/kheaders_data.tar.xz
      CC [M]  kernel/configs.o
      GEN     kernel/kheaders_data.tar.xz
      CC [M]  kernel/kheaders.o
      Building modules, stage 2.
    Kernel: arch/x86/boot/bzImage is ready  (#9)
      MODPOST 7282 modules
      LD [M]  kernel/configs.ko
      LD [M]  kernel/kheaders.ko

    real        0m41.326s
    user        2m17.822s
    sys 0m54.561s

No, this isn't the end of the world, but if somebody sees a simple
solution to avoid that extra ten seconds, I'd appreciate it.

                  Linus