linux-kernel - Re: [PATCH v2 2/7] x86: use long long for 64-bit atomic ops

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: <CACT4Y+aptgVy4Co0WcsZ9sbDpKSJAM58oFOwBRQK99arMf5a+w@mail.gmail.com>
Date:   Mon, 29 May 2017 13:03:32 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Heiko Carstens <heiko.carstens@...ibm.com>
Cc:     Mark Rutland <mark.rutland@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Will Deacon <will.deacon@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        kasan-dev <kasan-dev@...glegroups.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Matthew Wilcox <willy@...radead.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH v2 2/7] x86: use long long for 64-bit atomic ops

On Mon, May 29, 2017 at 12:49 PM, Heiko Carstens
<heiko.carstens@...ibm.com> wrote:
> On Fri, May 26, 2017 at 09:09:04PM +0200, Dmitry Vyukov wrote:
>> Some 64-bit atomic operations use 'long long' as operand/return type
>> (e.g. asm-generic/atomic64.h, arch/x86/include/asm/atomic64_32.h);
>> while others use 'long' (e.g. arch/x86/include/asm/atomic64_64.h).
>> This makes it impossible to write portable code.
>> For example, there is no format specifier that prints result of
>> atomic64_read() without warnings. atomic64_try_cmpxchg() is almost
>> impossible to use in portable fashion because it requires either
>> 'long *' or 'long long *' as argument depending on arch.
>>
>> Switch arch/x86/include/asm/atomic64_64.h to 'long long'.
>>
>> Signed-off-by: Dmitry Vyukov <dvyukov@...gle.com>
>>
>> ---
>> Changes since v1:
>>  - reverted stray s/long/long long/ replace in comment
>>  - added arch/s390 changes to fix build errors/warnings
>
> If you change s390 code, please add the relevant mailing list and/or
> maintainers please.
>
>> diff --git a/arch/s390/include/asm/atomic_ops.h b/arch/s390/include/asm/atomic_ops.h
>> index ac9e2b939d04..055a9083e52d 100644
>> --- a/arch/s390/include/asm/atomic_ops.h
>> +++ b/arch/s390/include/asm/atomic_ops.h
>> @@ -31,10 +31,10 @@ __ATOMIC_OPS(__atomic_and, int, "lan")
>>  __ATOMIC_OPS(__atomic_or,  int, "lao")
>>  __ATOMIC_OPS(__atomic_xor, int, "lax")
>>
>> -__ATOMIC_OPS(__atomic64_add, long, "laag")
>> -__ATOMIC_OPS(__atomic64_and, long, "lang")
>> -__ATOMIC_OPS(__atomic64_or,  long, "laog")
>> -__ATOMIC_OPS(__atomic64_xor, long, "laxg")
>> +__ATOMIC_OPS(__atomic64_add, long long, "laag")
>> +__ATOMIC_OPS(__atomic64_and, long long, "lang")
>> +__ATOMIC_OPS(__atomic64_or,  long long, "laog")
>> +__ATOMIC_OPS(__atomic64_xor, long long, "laxg")
>>
>>  #undef __ATOMIC_OPS
>>  #undef __ATOMIC_OP
>> @@ -46,7 +46,7 @@ static inline void __atomic_add_const(int val, int *ptr)
>>               : [ptr] "+Q" (*ptr) : [val] "i" (val) : "cc");
>>  }
>>
>> -static inline void __atomic64_add_const(long val, long *ptr)
>> +static inline void __atomic64_add_const(long val, long long *ptr)
>
> If you change this then val should be long long (or s64) too.
>
>> -static inline long op_name(long val, long *ptr)                              \
>> +static inline long op_name(long val, long long *ptr)                 \
>>  {                                                                    \
>>       long old, new;                                                  \
>
> Same here. You only changed the type of *ptr, but left the rest
> alone. Everything should have the same type.

I will try to follow hpa's suggestion in the next version of the
patch. If it work out, I will not need to touch s390 code.

Still thanks for the review.