All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org,
	linux-arch@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Darren Hart <dvhart@infradead.org>, Shuah Khan <shuah@kernel.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	David Laight <David.Laight@ACULAB.COM>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment
Date: Mon, 9 Jul 2018 14:07:39 +0100	[thread overview]
Message-ID: <20180709130738.GA28336@arm.com> (raw)
In-Reply-To: <20180709124741.21037-1-abrodkin@synopsys.com>

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@synopsys.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Boqun Feng <boqun.feng@gmail.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Darren Hart <dvhart@infradead.org>
> Cc: Shuah Khan <shuah@kernel.org>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Cc: Josh Triplett <josh@joshtriplett.org>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: Lai Jiangshan <jiangshanlai@gmail.com>
> Cc: David Laight <David.Laight@ACULAB.COM>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.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;

Long long is 8-byte aligned per EABI ARM, and we use the generic atomic64
infrastructure for OABI, so we don't need to change anything here afaict.

Will

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment
Date: Mon, 9 Jul 2018 14:07:39 +0100	[thread overview]
Message-ID: <20180709130738.GA28336@arm.com> (raw)
In-Reply-To: <20180709124741.21037-1-abrodkin@synopsys.com>

On Mon, Jul 09, 2018@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 at synopsys.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Peter Zijlstra <peterz at infradead.org>
> Cc: Boqun Feng <boqun.feng at gmail.com>
> Cc: Russell King <linux at armlinux.org.uk>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Ingo Molnar <mingo at redhat.com>
> Cc: Darren Hart <dvhart at infradead.org>
> Cc: Shuah Khan <shuah at kernel.org>
> Cc: "Paul E. McKenney" <paulmck at linux.vnet.ibm.com>
> Cc: Josh Triplett <josh at joshtriplett.org>
> Cc: Steven Rostedt <rostedt at goodmis.org>
> Cc: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
> Cc: Lai Jiangshan <jiangshanlai at gmail.com>
> Cc: David Laight <David.Laight at ACULAB.COM>
> Cc: Geert Uytterhoeven <geert at linux-m68k.org>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.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;

Long long is 8-byte aligned per EABI ARM, and we use the generic atomic64
infrastructure for OABI, so we don't need to change anything here afaict.

Will

  parent reply	other threads:[~2018-07-09 13:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-09 12:47 [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment Alexey Brodkin
2018-07-09 12:47 ` Alexey Brodkin
2018-07-09 12:47 ` Alexey Brodkin
2018-07-09 12:55 ` Geert Uytterhoeven
2018-07-09 12:55   ` Geert Uytterhoeven
2018-07-09 13:07 ` Will Deacon [this message]
2018-07-09 13:07   ` Will Deacon
2018-07-09 13:30 ` David Laight
2018-07-09 13:30   ` David Laight
2018-07-09 13:30   ` David Laight
2018-07-09 13:49   ` Geert Uytterhoeven
2018-07-09 13:49     ` Geert Uytterhoeven
2018-07-09 13:49     ` Geert Uytterhoeven
2018-07-09 13:35 ` Peter Zijlstra
2018-07-09 13:35   ` Peter Zijlstra
2018-07-09 13:35   ` Peter Zijlstra
2018-07-09 14:30   ` Alexey Brodkin
2018-07-09 14:30     ` Alexey Brodkin
2018-07-09 14:30     ` Alexey Brodkin
2018-07-09 14:45     ` Peter Zijlstra
2018-07-09 14:45       ` Peter Zijlstra
2018-07-09 14:45       ` Peter Zijlstra
2018-07-09 14:04 ` Russell King - ARM Linux
2018-07-09 14:04   ` Russell King - ARM Linux
2018-07-09 16:25 ` kbuild test robot
2018-07-09 16:25   ` kbuild test robot
2018-07-09 16:25   ` kbuild test robot
2018-07-09 16:25   ` kbuild test robot
2018-07-09 18:05 ` kbuild test robot
2018-07-09 18:05   ` kbuild test robot
2018-07-09 18:05   ` kbuild test robot
2018-07-09 18:05   ` kbuild test robot

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=20180709130738.GA28336@arm.com \
    --to=will.deacon@arm.com \
    --cc=Alexey.Brodkin@synopsys.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=arnd@arndb.de \
    --cc=boqun.feng@gmail.com \
    --cc=dvhart@infradead.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    /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.