[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180709140421.GF17271@n2100.armlinux.org.uk>
Date: Mon, 9 Jul 2018 15:04:21 +0100
From: Russell King - ARM Linux <linux@...linux.org.uk>
To: Alexey Brodkin <Alexey.Brodkin@...opsys.com>
Cc: linux-kernel@...r.kernel.org, linux-snps-arc@...ts.infradead.org,
linux-arch@...r.kernel.org, Will Deacon <will.deacon@....com>,
Peter Zijlstra <peterz@...radead.org>,
Boqun Feng <boqun.feng@...il.com>,
Arnd Bergmann <arnd@...db.de>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Darren Hart <dvhart@...radead.org>,
Shuah Khan <shuah@...nel.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Josh Triplett <josh@...htriplett.org>,
Steven Rostedt <rostedt@...dmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Lai Jiangshan <jiangshanlai@...il.com>,
David Laight <David.Laight@...LAB.COM>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] atomic{64}_t: Explicitly specify data storage length and
alignment
On Mon, Jul 09, 2018 at 03:47:41PM +0300, Alexey Brodkin wrote:
> Atomic instructions require data they operate on to be aligned
> according to data size. I.e. 32-bit atomic values must be 32-bit
> aligned while 64-bit values must be 64-bit aligned.
>
> Otherwise even if CPU may handle not-aligend normal data access,
> still atomic instructions fail and typically raise an exception
> leaving us dead in the water.
>
> This came-up during lengthly discussion here:
> http://lists.infradead.org/pipermail/linux-snps-arc/2018-July/004022.html
>
> Signed-off-by: Alexey Brodkin <abrodkin@...opsys.com>
> Cc: Will Deacon <will.deacon@....com>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Boqun Feng <boqun.feng@...il.com>
> Cc: Russell King <linux@...linux.org.uk>
> Cc: Arnd Bergmann <arnd@...db.de>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: Darren Hart <dvhart@...radead.org>
> Cc: Shuah Khan <shuah@...nel.org>
> Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
> Cc: Josh Triplett <josh@...htriplett.org>
> Cc: Steven Rostedt <rostedt@...dmis.org>
> Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> Cc: Lai Jiangshan <jiangshanlai@...il.com>
> Cc: David Laight <David.Laight@...LAB.COM>
> Cc: Geert Uytterhoeven <geert@...ux-m68k.org>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> ---
> arch/arm/include/asm/atomic.h | 2 +-
> include/asm-generic/atomic64.h | 2 +-
> include/linux/types.h | 4 ++--
> tools/include/linux/types.h | 2 +-
> tools/testing/selftests/futex/include/atomic.h | 2 +-
> .../rcutorture/formal/srcu-cbmc/include/linux/types.h | 4 ++--
> 6 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
> index 66d0e215a773..2ed6d7cf1407 100644
> --- a/arch/arm/include/asm/atomic.h
> +++ b/arch/arm/include/asm/atomic.h
> @@ -267,7 +267,7 @@ ATOMIC_OPS(xor, ^=, eor)
>
> #ifndef CONFIG_GENERIC_ATOMIC64
> typedef struct {
> - long long counter;
> + u64 __aligned(8) counter;
> } atomic64_t;
ARM doesn't need or require this change, and you're changing the type
from signed to unsigned, which is likely to break stuff. So, NAK on
this from the ARM point of view.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
Powered by blists - more mailing lists