linux-kernel - Re: [PATCH v9 04/10] x86: refcount: prevent gcc distortions

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]

Date:   Thu, 4 Oct 2018 08:56:37 +0000
From:   Nadav Amit <namit@...are.com>
To:     "hpa@...or.com" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>
CC:     Ingo Molnar <mingo@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jan Beulich <JBeulich@...e.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH v9 04/10] x86: refcount: prevent gcc distortions

at 1:40 AM, hpa@...or.com wrote:

> On October 4, 2018 1:33:33 AM PDT, Ingo Molnar <mingo@...nel.org> wrote:
>> * Ingo Molnar <mingo@...nel.org> wrote:
>> 
>>> I'm also somewhat annoyed at the fact that this series carries a
>> boatload
>>> of reviewed-by's and acked-by's, yet none of those reviewers found it
>>> important to point out the large chasm that is gaping between
>> description
>>> and reality.
>> 
>> Another problem I just realized is that we now include
>> arch/x86/kernel/macros.S in every 
>> translation pass when building the kernel, right?
>> 
>> But arch/x86/kernel/macros.S expands to a pretty large hiearchy of
>> header files:
>> 
>> $ make arch/x86/kernel/macros.s
>> 
>> $ cat $(grep include arch/x86/kernel/macros.s | cut -d\" -f2 | sort |
>> uniq) | wc -l
>> 4128
>> 
>> That's 4,100 extra lines of code to be preprocessed for every
>> translation unit, of
>> which there are tens of thousands. More if other pieces of code get
>> macrofied in
>> this fasion in the future.
>> 
>> If we assume that a typical distribution kernel build has ~20,000
>> translation units
>> then this change adds 82,560,000 more lines to be preprocessed, just to
>> work around
>> a stupid GCC bug?
>> 
>> I'm totally unhappy about that. Can we do this without adding macros.S?
>> 
>> It's also a pretty stupidly central file anyway that moves source code
>> away
>> from where it's used.
>> 
>> Thanks,
>> 
>> 	Ingo
> 
> It's not just for working around a stupid GCC bug, but it also has a huge
> potential for cleaning up the inline asm in general.
> 
> I would like to know if there is an actual number for the build overhead
> (an actual benchmark); I have asked for that once already.

I can run some tests. (@hpa: I thought you asked about the -pipe overhead;
perhaps I misunderstood).

I guess you regard to the preprocessing of the assembler. Note that the C 
preprocessing of macros.S obviously happens only once. That’s the reason
I assumed it’s not that expensive.

Anyhow, I remember that we discussed at some point doing something like
‘asm(“.include XXX.s”)’ and somebody said it is not good, but I don’t
remember why and don’t see any reason it is so. Unless I am missing
something, I think it is possible to take each individual header and
preprocess the assembly part of into a separate .s file. Then we can put in
the C part of the header ‘asm(".include XXX.s”)’.

What do you think?