linux-kernel - Re: [tip:locking/core] locking/atomics: Check generated headers are up-to-date

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 28 Nov 2018 09:30:57 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Mark Rutland <mark.rutland@....com>
Cc:     tglx@...utronix.de, hpa@...or.com, linux-kernel@...r.kernel.org,
        peterz@...radead.org, boqun.feng@...il.com, will.deacon@....com,
        linux-tip-commits@...r.kernel.org, akpm@...ux-foundation.org,
        torvalds@...ux-foundation.org
Subject: Re: [tip:locking/core] locking/atomics: Check generated headers are
 up-to-date


* Mark Rutland <mark.rutland@....com> wrote:

> > Could we please get this fixed so that proper dependencies are checked 
> > and it's only regenerated when needed? This slowdown makes additive-build 
> > kernel development quite painful, as ~5 seconds is in the 'too long' 
> > category already, while 1.2 seconds is basically instantaneous.
> 
> Just to check, are we happy to eat the full cost for the first build of a
> pristine tree?

No, not happy to add 3-4 seconds to a full build that usually takes less 
than 60 seconds. This stuff isn't parallelized nor particularly well 
optimized it appears.

This *must* get faster.

> One reason we do the check rather than (re-)generating the headers is 
> that Linus requested [1] the generated header be committed so that they 
> show up in git grep, but it looks like he was happy to be flexible on 
> that.

I think the generated headers should be part of the commit space, the 
grepping is important.

> If we're happy to not commit in the generated headers, and if we're happy to
> pay the cost for a pristine tree, that's fairly straightforward to do.
> Otherwise, this has to be an optional check.

Or faster code, or a different concept!

Thanks,

	Ingo