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: <CAK7LNAQd5+-+fcmy3PMH1V6eDckXaeibv_vVgP5GX5L7j-2nEw@mail.gmail.com>
Date:   Fri, 10 May 2019 15:20:27 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        "Joel Fernandes (Google)" <joel@...lfernandes.org>,
        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

Hi Linus,


On Fri, May 10, 2019 at 5:50 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> [ 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:

Yeah, I have had this in my mind for a while.

If you run "make *config" and it happens to be creating
the exactly the same .config, Kconfig should not overwrite
it at all.

If you apply the following two,
I hope you will get the behavior you like.

https://patchwork.kernel.org/patch/10938255/
https://patchwork.kernel.org/patch/10938253/

(1/2 is just a cleanup because I am touching the
same hunk.)

Because I have not sent a Kconfig pull request yet
in the current MW, I will consider to merge them.

Thanks.


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



-- 
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ