linux-kernel - Re: [PATCH 2/3] asm-generic, x86: wrap atomic operations

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:   Tue, 28 Mar 2017 11:56:32 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Mark Rutland <mark.rutland@....com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Ingo Molnar <mingo@...hat.com>,
        Will Deacon <will.deacon@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        kasan-dev <kasan-dev@...glegroups.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "x86@...nel.org" <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 2/3] asm-generic, x86: wrap atomic operations

On Tue, Mar 28, 2017 at 11:51 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Peter Zijlstra <peterz@...radead.org> wrote:
>
>> On Tue, Mar 28, 2017 at 09:52:32AM +0200, Ingo Molnar wrote:
>>
>> > No, regular C code.
>> >
>> > I don't see the point of generating all this code via CPP - it's certainly not
>> > making it more readable to me. I.e. this patch I commented on is a step backwards
>> > for readability.
>>
>> Note that much of the atomic stuff we have today is all CPP already.
>
> Yeah, but there it's implementational: we pick up arch primitives depending on
> whether they are defined, such as:
>
> #ifndef atomic_read_acquire
> # define atomic_read_acquire(v)         smp_load_acquire(&(v)->counter)
> #endif
>
>> x86 is the exception because its 'weird', but most other archs are
>> almost pure CPP -- check Alpha for example, or asm-generic/atomic.h.
>
> include/asm-generic/atomic.h looks pretty clean and readable overall.
>
>> Also, look at linux/atomic.h, its a giant maze of CPP.
>
> Nah, that's OK, much of is is essentially __weak inlines implemented via CPP -
> i.e. CPP is filling in a missing compiler feature.
>
> But this patch I replied to appears to add instrumentation wrappery via CPP which
> looks like excessive and avoidable obfuscation to me.
>
> If it's much more readable and much more compact than the C version then maybe,
> but I'd like to see the C version first and see ...
>
>> The CPP help us generate functions, reduces endless copy/paste (which induces
>> random differences -- read bugs) and construct variants depending on the
>> architecture input.
>>
>> Yes, the CPP is a pain, but writing all that out explicitly is more of a
>> pain.
>
> So I'm not convinced that it's true in this case.
>
> Could we see the C version and compare? I could be wrong about it all.

Here it is (without instrumentation):
https://gist.github.com/dvyukov/e33d580f701019e0cd99429054ff1f9a

Instrumentation will add for each function:

 static __always_inline void atomic64_set(atomic64_t *v, long long i)
 {
+       kasan_check_write(v, sizeof(*v));
        arch_atomic64_set(v, i);
 }