From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: mark.rutland@arm.com, peterz@infradead.org, mingo@redhat.com,
will.deacon@arm.com, akpm@linux-foundation.org,
aryabinin@virtuozzo.com, kasan-dev@googlegroups.com,
linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de,
hpa@zytor.com, willy@infradead.org, linux-mm@kvack.org
Subject: Re: [PATCH v2 2/7] x86: use long long for 64-bit atomic ops
Date: Mon, 29 May 2017 12:49:16 +0200 [thread overview]
Message-ID: <20170529104916.GB12975@osiris> (raw)
In-Reply-To: <3758f3da9de01b1a082c4e1f44ba3b48f7a840ea.1495825151.git.dvyukov@google.com>
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@google.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.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: mark.rutland@arm.com, peterz@infradead.org, mingo@redhat.com,
will.deacon@arm.com, akpm@linux-foundation.org,
aryabinin@virtuozzo.com, kasan-dev@googlegroups.com,
linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de,
hpa@zytor.com, willy@infradead.org, linux-mm@kvack.org
Subject: Re: [PATCH v2 2/7] x86: use long long for 64-bit atomic ops
Date: Mon, 29 May 2017 12:49:16 +0200 [thread overview]
Message-ID: <20170529104916.GB12975@osiris> (raw)
In-Reply-To: <3758f3da9de01b1a082c4e1f44ba3b48f7a840ea.1495825151.git.dvyukov@google.com>
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@google.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.
next prev parent reply other threads:[~2017-05-29 10:49 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-26 19:09 [PATCH v2 0/7] x86, kasan: add KASAN checks to atomic operations Dmitry Vyukov
2017-05-26 19:09 ` [PATCH v2 1/7] x86: un-macro-ify atomic ops implementation Dmitry Vyukov
2017-05-26 19:09 ` [PATCH v2 2/7] x86: use long long for 64-bit atomic ops Dmitry Vyukov
2017-05-26 19:09 ` Dmitry Vyukov
2017-05-27 23:02 ` hpa
2017-05-27 23:02 ` hpa
2017-05-28 9:29 ` Dmitry Vyukov
2017-05-28 9:29 ` Dmitry Vyukov
2017-05-28 9:34 ` hpa
2017-05-28 9:34 ` hpa
2017-05-29 14:44 ` Dmitry Vyukov
2017-05-29 14:44 ` Dmitry Vyukov
2017-06-06 10:12 ` Dmitry Vyukov
2017-06-06 10:12 ` Dmitry Vyukov
2017-05-29 10:49 ` Heiko Carstens [this message]
2017-05-29 10:49 ` Heiko Carstens
2017-05-29 11:03 ` Dmitry Vyukov
2017-05-29 11:03 ` Dmitry Vyukov
2017-05-26 19:09 ` [PATCH v2 3/7] asm-generic: add atomic-instrumented.h Dmitry Vyukov
2017-05-26 19:09 ` Dmitry Vyukov
2017-05-26 19:09 ` [PATCH v2 4/7] x86: switch atomic.h to use atomic-instrumented.h Dmitry Vyukov
2017-05-26 19:09 ` Dmitry Vyukov
2017-05-26 19:09 ` [PATCH v2 5/7] kasan: allow kasan_check_read/write() to accept pointers to volatiles Dmitry Vyukov
2017-05-26 19:09 ` Dmitry Vyukov
2017-05-26 19:09 ` [PATCH v2 6/7] asm-generic: add KASAN instrumentation to atomic operations Dmitry Vyukov
2017-05-26 19:09 ` Dmitry Vyukov
2017-05-26 19:09 ` [PATCH v2 7/7] asm-generic, x86: add comments for atomic instrumentation Dmitry Vyukov
2017-05-26 19:09 ` Dmitry Vyukov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170529104916.GB12975@osiris \
--to=heiko.carstens@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=dvyukov@google.com \
--cc=hpa@zytor.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.