linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment
@ 2018-07-09 12:47 Alexey Brodkin
  2018-07-09 12:55 ` Geert Uytterhoeven
                   ` (6 more replies)
  0 siblings, 7 replies; 11+ messages in thread
From: Alexey Brodkin @ 2018-07-09 12:47 UTC (permalink / raw)
  To: linux-kernel
  Cc: linux-snps-arc, linux-arch, Alexey Brodkin, Will Deacon,
	Peter Zijlstra, Boqun Feng, Russell King, Arnd Bergmann,
	Thomas Gleixner, Ingo Molnar, Darren Hart, Shuah Khan,
	Paul E. McKenney, Josh Triplett, Steven Rostedt,
	Mathieu Desnoyers, Lai Jiangshan, David Laight,
	Geert Uytterhoeven, Greg Kroah-Hartman

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;
 
 #define ATOMIC64_INIT(i) { (i) }
diff --git a/include/asm-generic/atomic64.h b/include/asm-generic/atomic64.h
index 8d28eb010d0d..b94b749b5952 100644
--- a/include/asm-generic/atomic64.h
+++ b/include/asm-generic/atomic64.h
@@ -13,7 +13,7 @@
 #define _ASM_GENERIC_ATOMIC64_H
 
 typedef struct {
-	long long counter;
+	u64 __aligned(8) counter;
 } atomic64_t;
 
 #define ATOMIC64_INIT(i)	{ (i) }
diff --git a/include/linux/types.h b/include/linux/types.h
index 9834e90aa010..e2f631782621 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -174,12 +174,12 @@ typedef phys_addr_t resource_size_t;
 typedef unsigned long irq_hw_number_t;
 
 typedef struct {
-	int counter;
+	u32 __aligned(4) counter;
 } atomic_t;
 
 #ifdef CONFIG_64BIT
 typedef struct {
-	long counter;
+	u64 __aligned(8) counter;
 } atomic64_t;
 #endif
 
diff --git a/tools/include/linux/types.h b/tools/include/linux/types.h
index 154eb4e3ca7c..c913e26ea4eb 100644
--- a/tools/include/linux/types.h
+++ b/tools/include/linux/types.h
@@ -59,7 +59,7 @@ typedef __u64 __bitwise __le64;
 typedef __u64 __bitwise __be64;
 
 typedef struct {
-	int counter;
+	u32 __aligned(4) counter;
 } atomic_t;
 
 #ifndef __aligned_u64
diff --git a/tools/testing/selftests/futex/include/atomic.h b/tools/testing/selftests/futex/include/atomic.h
index f861da3e31ab..34e14295e492 100644
--- a/tools/testing/selftests/futex/include/atomic.h
+++ b/tools/testing/selftests/futex/include/atomic.h
@@ -23,7 +23,7 @@
 #define _ATOMIC_H
 
 typedef struct {
-	volatile int val;
+	volatile u32 __aligned(4) val;
 } atomic_t;
 
 #define ATOMIC_INITIALIZER { 0 }
diff --git a/tools/testing/selftests/rcutorture/formal/srcu-cbmc/include/linux/types.h b/tools/testing/selftests/rcutorture/formal/srcu-cbmc/include/linux/types.h
index 891ad13e95b2..32ce965187b3 100644
--- a/tools/testing/selftests/rcutorture/formal/srcu-cbmc/include/linux/types.h
+++ b/tools/testing/selftests/rcutorture/formal/srcu-cbmc/include/linux/types.h
@@ -100,12 +100,12 @@ typedef phys_addr_t resource_size_t;
 typedef unsigned long irq_hw_number_t;
 
 typedef struct {
-	int counter;
+	u32 __aligned(4) counter;
 } atomic_t;
 
 #ifdef CONFIG_64BIT
 typedef struct {
-	long counter;
+	u64 __aligned(8) counter;
 } atomic64_t;
 #endif
 
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment
  2018-07-09 12:47 [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment Alexey Brodkin
@ 2018-07-09 12:55 ` Geert Uytterhoeven
  2018-07-09 13:07 ` Will Deacon
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 11+ messages in thread
From: Geert Uytterhoeven @ 2018-07-09 12:55 UTC (permalink / raw)
  To: Alexey Brodkin
  Cc: Linux Kernel Mailing List, arcml, Linux-Arch, Will Deacon,
	Peter Zijlstra, Boqun Feng, Russell King, Arnd Bergmann,
	Thomas Gleixner, Ingo Molnar, Darren Hart, Shuah Khan,
	Paul E. McKenney, Josh Triplett, Steven Rostedt,
	Mathieu Desnoyers, Lai Jiangshan, David Laight, Greg KH

Hi Alexey,

On Mon, Jul 9, 2018 at 2:48 PM Alexey Brodkin
<Alexey.Brodkin@synopsys.com> 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>

Thanks for your patch!

> --- a/include/asm-generic/atomic64.h
> +++ b/include/asm-generic/atomic64.h
> @@ -13,7 +13,7 @@
>  #define _ASM_GENERIC_ATOMIC64_H
>
>  typedef struct {
> -       long long counter;
> +       u64 __aligned(8) counter;

I think you can drop the change to this file, as this is the generic
implementation using spinlocks, for processors that don't have 64-bit atomic
instructions.

>  } atomic64_t;

Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment
  2018-07-09 12:47 [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment Alexey Brodkin
  2018-07-09 12:55 ` Geert Uytterhoeven
@ 2018-07-09 13:07 ` Will Deacon
  2018-07-09 13:30 ` David Laight
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 11+ messages in thread
From: Will Deacon @ 2018-07-09 13:07 UTC (permalink / raw)
  To: Alexey Brodkin
  Cc: linux-kernel, linux-snps-arc, linux-arch, Peter Zijlstra,
	Boqun Feng, Russell King, Arnd Bergmann, Thomas Gleixner,
	Ingo Molnar, Darren Hart, Shuah Khan, Paul E. McKenney,
	Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan,
	David Laight, Geert Uytterhoeven, Greg Kroah-Hartman

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment
  2018-07-09 12:47 [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment Alexey Brodkin
  2018-07-09 12:55 ` Geert Uytterhoeven
  2018-07-09 13:07 ` Will Deacon
@ 2018-07-09 13:30 ` David Laight
  2018-07-09 13:49   ` Geert Uytterhoeven
  2018-07-09 13:35 ` Peter Zijlstra
                   ` (3 subsequent siblings)
  6 siblings, 1 reply; 11+ messages in thread
From: David Laight @ 2018-07-09 13:30 UTC (permalink / raw)
  To: 'Alexey Brodkin', linux-kernel
  Cc: linux-snps-arc, linux-arch, Will Deacon, Peter Zijlstra,
	Boqun Feng, Russell King, Arnd Bergmann, Thomas Gleixner,
	Ingo Molnar, Darren Hart, Shuah Khan, Paul E. McKenney,
	Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan,
	Geert Uytterhoeven, Greg Kroah-Hartman

From: Alexey Brodkin
> Sent: 09 July 2018 13:48
> 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.
...
> diff --git a/include/asm-generic/atomic64.h b/include/asm-generic/atomic64.h
> index 8d28eb010d0d..b94b749b5952 100644
> --- a/include/asm-generic/atomic64.h
> +++ b/include/asm-generic/atomic64.h
> @@ -13,7 +13,7 @@
>  #define _ASM_GENERIC_ATOMIC64_H
> 
>  typedef struct {
> -	long long counter;
> +	u64 __aligned(8) counter;
>  } atomic64_t;

Apart from the fact that this changes the value from signed to unsigned
should most of the architectures be using this generic definition?

The only exceptions would be 32bit architectures that lack 64bit
instructions (eg m68k).

	David


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment
  2018-07-09 12:47 [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment Alexey Brodkin
                   ` (2 preceding siblings ...)
  2018-07-09 13:30 ` David Laight
@ 2018-07-09 13:35 ` Peter Zijlstra
  2018-07-09 14:30   ` Alexey Brodkin
  2018-07-09 14:04 ` Russell King - ARM Linux
                   ` (2 subsequent siblings)
  6 siblings, 1 reply; 11+ messages in thread
From: Peter Zijlstra @ 2018-07-09 13:35 UTC (permalink / raw)
  To: Alexey Brodkin
  Cc: linux-kernel, linux-snps-arc, linux-arch, Will Deacon,
	Boqun Feng, Russell King, Arnd Bergmann, Thomas Gleixner,
	Ingo Molnar, Darren Hart, Shuah Khan, Paul E. McKenney,
	Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan,
	David Laight, Geert Uytterhoeven, Greg Kroah-Hartman

On Mon, Jul 09, 2018 at 03:47:41PM +0300, Alexey Brodkin wrote:
> diff --git a/include/asm-generic/atomic64.h b/include/asm-generic/atomic64.h
> index 8d28eb010d0d..b94b749b5952 100644
> --- a/include/asm-generic/atomic64.h
> +++ b/include/asm-generic/atomic64.h
> @@ -13,7 +13,7 @@
>  #define _ASM_GENERIC_ATOMIC64_H
>  
>  typedef struct {
> -	long long counter;
> +	u64 __aligned(8) counter;
>  } atomic64_t;

The type is wrong, atomic is signed, the alignment also really doesn't
matter, generic atomic64 is utter crap.

>  #define ATOMIC64_INIT(i)	{ (i) }
> diff --git a/include/linux/types.h b/include/linux/types.h
> index 9834e90aa010..e2f631782621 100644
> --- a/include/linux/types.h
> +++ b/include/linux/types.h
> @@ -174,12 +174,12 @@ typedef phys_addr_t resource_size_t;
>  typedef unsigned long irq_hw_number_t;
>  
>  typedef struct {
> -	int counter;
> +	u32 __aligned(4) counter;
>  } atomic_t;

u32 is wrong, the atomic type is signed.

Also, if an architecture doesn't properly align its native machine word
size but requires alignment for atomics it's a broken architecture.

>  
>  #ifdef CONFIG_64BIT
>  typedef struct {
> -	long counter;
> +	u64 __aligned(8) counter;
>  } atomic64_t;
>  #endif
>  

Similar for this one, on 64bit archs that support atomics the native
64bit types (long included) had better already imply this alignment.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment
  2018-07-09 13:30 ` David Laight
@ 2018-07-09 13:49   ` Geert Uytterhoeven
  0 siblings, 0 replies; 11+ messages in thread
From: Geert Uytterhoeven @ 2018-07-09 13:49 UTC (permalink / raw)
  To: David Laight
  Cc: Alexey Brodkin, Linux Kernel Mailing List, arcml, Linux-Arch,
	Will Deacon, Peter Zijlstra, Boqun Feng, Russell King,
	Arnd Bergmann, Thomas Gleixner, Ingo Molnar, Darren Hart,
	Shuah Khan, Paul E. McKenney, Josh Triplett, Steven Rostedt,
	Mathieu Desnoyers, Lai Jiangshan, Greg KH

On Mon, Jul 9, 2018 at 3:29 PM David Laight <David.Laight@aculab.com> wrote:
> From: Alexey Brodkin
> > Sent: 09 July 2018 13:48
> > 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.
> ...
> > diff --git a/include/asm-generic/atomic64.h b/include/asm-generic/atomic64.h
> > index 8d28eb010d0d..b94b749b5952 100644
> > --- a/include/asm-generic/atomic64.h
> > +++ b/include/asm-generic/atomic64.h
> > @@ -13,7 +13,7 @@
> >  #define _ASM_GENERIC_ATOMIC64_H
> >
> >  typedef struct {
> > -     long long counter;
> > +     u64 __aligned(8) counter;
> >  } atomic64_t;
>
> Apart from the fact that this changes the value from signed to unsigned
> should most of the architectures be using this generic definition?

64-bit architectures use the one from include/linux/types.h instead.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment
  2018-07-09 12:47 [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment Alexey Brodkin
                   ` (3 preceding siblings ...)
  2018-07-09 13:35 ` Peter Zijlstra
@ 2018-07-09 14:04 ` Russell King - ARM Linux
  2018-07-09 16:25 ` kbuild test robot
  2018-07-09 18:05 ` kbuild test robot
  6 siblings, 0 replies; 11+ messages in thread
From: Russell King - ARM Linux @ 2018-07-09 14:04 UTC (permalink / raw)
  To: Alexey Brodkin
  Cc: linux-kernel, linux-snps-arc, linux-arch, Will Deacon,
	Peter Zijlstra, Boqun Feng, Arnd Bergmann, Thomas Gleixner,
	Ingo Molnar, Darren Hart, Shuah Khan, Paul E. McKenney,
	Josh Triplett, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan,
	David Laight, Geert Uytterhoeven, Greg Kroah-Hartman

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;

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment
  2018-07-09 13:35 ` Peter Zijlstra
@ 2018-07-09 14:30   ` Alexey Brodkin
  2018-07-09 14:45     ` Peter Zijlstra
  0 siblings, 1 reply; 11+ messages in thread
From: Alexey Brodkin @ 2018-07-09 14:30 UTC (permalink / raw)
  To: peterz
  Cc: linux-kernel, rostedt, josh, linux, tglx, dvhart, linux-snps-arc,
	paulmck, will.deacon, boqun.feng, jiangshanlai, gregkh,
	David.Laight, mingo, shuah, arnd, linux-arch, geert,
	mathieu.desnoyers

Hi Peter,

On Mon, 2018-07-09 at 15:35 +0200, Peter Zijlstra wrote:
> On Mon, Jul 09, 2018 at 03:47:41PM +0300, Alexey Brodkin wrote:
> > diff --git a/include/asm-generic/atomic64.h b/include/asm-generic/atomic64.h
> > index 8d28eb010d0d..b94b749b5952 100644
> > --- a/include/asm-generic/atomic64.h
> > +++ b/include/asm-generic/atomic64.h
> > @@ -13,7 +13,7 @@
> >  #define _ASM_GENERIC_ATOMIC64_H
> >  
> >  typedef struct {
> > -	long long counter;
> > +	u64 __aligned(8) counter;
> >  } atomic64_t;
> 
> The type is wrong, atomic is signed, the alignment also really doesn't
> matter, generic atomic64 is utter crap.

Hm, any thoughts on why it's "u64" for 32-bit x86?
See https://elixir.bootlin.com/linux/latest/source/arch/x86/include/asm/atomic64_32.h#L12
------------------------->8-----------------------
/* An 64bit atomic type */

typedef struct {
	u64 __aligned(8) counter;
} atomic64_t;
------------------------->8-----------------------

> >  #define ATOMIC64_INIT(i)	{ (i) }
> > diff --git a/include/linux/types.h b/include/linux/types.h
> > index 9834e90aa010..e2f631782621 100644
> > --- a/include/linux/types.h
> > +++ b/include/linux/types.h
> > @@ -174,12 +174,12 @@ typedef phys_addr_t resource_size_t;
> >  typedef unsigned long irq_hw_number_t;
> >  
> >  typedef struct {
> > -	int counter;
> > +	u32 __aligned(4) counter;
> >  } atomic_t;
> 
> u32 is wrong, the atomic type is signed.
> 
> Also, if an architecture doesn't properly align its native machine word
> size but requires alignment for atomics it's a broken architecture.

Ok we may not touch 32-bit atomics as there's a hope most of arches
properly align native machine words.

> >  
> >  #ifdef CONFIG_64BIT
> >  typedef struct {
> > -	long counter;
> > +	u64 __aligned(8) counter;
> >  } atomic64_t;
> >  #endif
> >  
> 
> Similar for this one, on 64bit archs that support atomics the native
> 64bit types (long included) had better already imply this alignment.

Ok agree.

-Alexey

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment
  2018-07-09 14:30   ` Alexey Brodkin
@ 2018-07-09 14:45     ` Peter Zijlstra
  0 siblings, 0 replies; 11+ messages in thread
From: Peter Zijlstra @ 2018-07-09 14:45 UTC (permalink / raw)
  To: Alexey Brodkin
  Cc: linux-kernel, rostedt, josh, linux, tglx, dvhart, linux-snps-arc,
	paulmck, will.deacon, boqun.feng, jiangshanlai, gregkh,
	David.Laight, mingo, shuah, arnd, linux-arch, geert,
	mathieu.desnoyers

On Mon, Jul 09, 2018 at 02:30:41PM +0000, Alexey Brodkin wrote:
> Hm, any thoughts on why it's "u64" for 32-bit x86?

Accident probably. It probably doesn't really matter all that much
because the kernel hard assumes 2s complement, but it is somewhat
inconsistent.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment
  2018-07-09 12:47 [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment Alexey Brodkin
                   ` (4 preceding siblings ...)
  2018-07-09 14:04 ` Russell King - ARM Linux
@ 2018-07-09 16:25 ` kbuild test robot
  2018-07-09 18:05 ` kbuild test robot
  6 siblings, 0 replies; 11+ messages in thread
From: kbuild test robot @ 2018-07-09 16:25 UTC (permalink / raw)
  To: Alexey Brodkin
  Cc: kbuild-all, linux-kernel, linux-snps-arc, linux-arch,
	Alexey Brodkin, Will Deacon, Peter Zijlstra, Boqun Feng,
	Russell King, Arnd Bergmann, Thomas Gleixner, Ingo Molnar,
	Darren Hart, Shuah Khan, Paul E. McKenney, Josh Triplett,
	Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, David Laight,
	Geert Uytterhoeven, Greg Kroah-Hartman

[-- Attachment #1: Type: text/plain, Size: 6783 bytes --]

Hi Alexey,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.18-rc4 next-20180709]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Alexey-Brodkin/atomic-64-_t-Explicitly-specify-data-storage-length-and-alignment/20180709-223920
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from tools/objtool/arch/x86/include/asm/orc_types.h:21:0,
                    from orc.h:21,
                    from orc_dump.c:19:
>> tools/include/linux/types.h:62:16: error: expected declaration specifiers or '...' before numeric constant
     u32 __aligned(4) counter;
                   ^
   tools/include/linux/types.h:63:1: error: no semicolon at end of struct or union [-Werror]
    } atomic_t;
    ^
   In file included from tools/objtool/arch/x86/include/asm/orc_types.h:21:0,
                    from orc.h:21,
                    from orc_gen.c:21:
>> tools/include/linux/types.h:62:16: error: expected declaration specifiers or '...' before numeric constant
     u32 __aligned(4) counter;
                   ^
   tools/include/linux/types.h:63:1: error: no semicolon at end of struct or union [-Werror]
    } atomic_t;
    ^
   In file included from tools/include/linux/string.h:5:0,
                    from ../lib/string.c:19:
>> tools/include/linux/types.h:62:16: error: expected declaration specifiers or '...' before numeric constant
     u32 __aligned(4) counter;
                   ^
   tools/include/linux/types.h:63:1: error: no semicolon at end of struct or union [-Werror]
    } atomic_t;
    ^
   cc1: all warnings being treated as errors
>> mv: cannot stat 'tools/objtool/.libstring.o.tmp': No such file or directory
   make[4]: *** [tools/objtool/libstring.o] Error 1
   In file included from tools/include/linux/string.h:5:0,
                    from ../lib/str_error_r.c:5:
>> tools/include/linux/types.h:62:16: error: expected declaration specifiers or '...' before numeric constant
     u32 __aligned(4) counter;
                   ^
   tools/include/linux/types.h:63:1: error: no semicolon at end of struct or union [-Werror]
    } atomic_t;
    ^
   cc1: all warnings being treated as errors
   In file included from tools/include/linux/list.h:5:0,
                    from elf.h:23,
                    from elf.c:31:
>> tools/include/linux/types.h:62:16: error: expected declaration specifiers or '...' before numeric constant
     u32 __aligned(4) counter;
                   ^
   tools/include/linux/types.h:63:1: error: no semicolon at end of struct or union [-Werror]
    } atomic_t;
    ^
   In file included from tools/include/linux/list.h:5:0,
                    from elf.h:23,
                    from special.h:22,
                    from special.c:26:
>> tools/include/linux/types.h:62:16: error: expected declaration specifiers or '...' before numeric constant
     u32 __aligned(4) counter;
                   ^
   tools/include/linux/types.h:63:1: error: no semicolon at end of struct or union [-Werror]
    } atomic_t;
    ^
   mv: cannot stat 'tools/objtool/.str_error_r.o.tmp': No such file or directory
   make[4]: *** [tools/objtool/str_error_r.o] Error 1
   In file included from tools/include/linux/string.h:5:0,
                    from run-command.c:7:
>> tools/include/linux/types.h:62:16: error: expected declaration specifiers or '...' before numeric constant
     u32 __aligned(4) counter;
                   ^
   tools/include/linux/types.h:63:1: error: no semicolon at end of struct or union [-Werror]
    } atomic_t;
    ^
   cc1: all warnings being treated as errors
   mv: cannot stat 'tools/objtool/.orc_dump.o.tmp': No such file or directory
   make[4]: *** [tools/objtool/orc_dump.o] Error 1
   In file included from tools/include/linux/string.h:5:0,
                    from help.c:5:
>> tools/include/linux/types.h:62:16: error: expected declaration specifiers or '...' before numeric constant
     u32 __aligned(4) counter;
                   ^
   tools/include/linux/types.h:63:1: error: no semicolon at end of struct or union [-Werror]
    } atomic_t;
    ^
   cc1: all warnings being treated as errors
   mv: cannot stat 'tools/objtool/.special.o.tmp': No such file or directory
   make[4]: *** [tools/objtool/special.o] Error 1
   cc1: all warnings being treated as errors
   cc1: all warnings being treated as errors
   mv: cannot stat 'tools/objtool/.run-command.o.tmp': No such file or directory
   make[5]: *** [tools/objtool/run-command.o] Error 1
   mv: cannot stat 'tools/objtool/.orc_gen.o.tmp': No such file or directory
   make[4]: *** [tools/objtool/orc_gen.o] Error 1
   cc1: all warnings being treated as errors
   mv: cannot stat 'tools/objtool/.help.o.tmp': No such file or directory
   make[5]: *** [tools/objtool/help.o] Error 1
   cc1: all warnings being treated as errors
   mv: cannot stat 'tools/objtool/.elf.o.tmp': No such file or directory
   make[4]: *** [tools/objtool/elf.o] Error 1
   In file included from tools/include/linux/list.h:5:0,
                    from arch/x86/../../elf.h:23,
                    from arch/x86/decode.c:26:
>> tools/include/linux/types.h:62:16: error: expected declaration specifiers or '...' before numeric constant
     u32 __aligned(4) counter;
                   ^
   tools/include/linux/types.h:63:1: error: no semicolon at end of struct or union [-Werror]
    } atomic_t;
    ^
   cc1: all warnings being treated as errors
   mv: cannot stat 'tools/objtool/arch/x86/.decode.o.tmp': No such file or directory
   make[5]: *** [tools/objtool/arch/x86/decode.o] Error 1
   make[5]: Target '__build' not remade because of errors.
   make[4]: *** [arch/x86] Error 2
   make[5]: Target '__build' not remade because of errors.
   make[4]: *** [tools/objtool/libsubcmd-in.o] Error 2
   make[4]: Target 'all' not remade because of errors.
   make[3]: *** [tools/objtool/libsubcmd.a] Error 2
   make[4]: Target '__build' not remade because of errors.
   make[3]: *** [tools/objtool/objtool-in.o] Error 2
   make[3]: Target 'all' not remade because of errors.
   make[2]: *** [objtool] Error 2
   make[1]: *** [tools/objtool] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +62 tools/include/linux/types.h

    60	
    61	typedef struct {
  > 62		u32 __aligned(4) counter;
    63	} atomic_t;
    64	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 30712 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment
  2018-07-09 12:47 [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment Alexey Brodkin
                   ` (5 preceding siblings ...)
  2018-07-09 16:25 ` kbuild test robot
@ 2018-07-09 18:05 ` kbuild test robot
  6 siblings, 0 replies; 11+ messages in thread
From: kbuild test robot @ 2018-07-09 18:05 UTC (permalink / raw)
  To: Alexey Brodkin
  Cc: kbuild-all, linux-kernel, linux-snps-arc, linux-arch,
	Alexey Brodkin, Will Deacon, Peter Zijlstra, Boqun Feng,
	Russell King, Arnd Bergmann, Thomas Gleixner, Ingo Molnar,
	Darren Hart, Shuah Khan, Paul E. McKenney, Josh Triplett,
	Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, David Laight,
	Geert Uytterhoeven, Greg Kroah-Hartman

[-- Attachment #1: Type: text/plain, Size: 22633 bytes --]

Hi Alexey,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.18-rc4 next-20180709]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Alexey-Brodkin/atomic-64-_t-Explicitly-specify-data-storage-length-and-alignment/20180709-223920
config: s390-allmodconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.2.0 make.cross ARCH=s390 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/atomic.h:5:0,
                    from include/linux/debug_locks.h:6,
                    from include/linux/lockdep.h:28,
                    from include/linux/spinlock_types.h:18,
                    from kernel/bounds.c:14:
   arch/s390/include/asm/atomic.h: In function 'atomic64_add_return':
>> arch/s390/include/asm/atomic.h:129:35: error: passing argument 2 of '__atomic64_add_barrier' from incompatible pointer type [-Werror=incompatible-pointer-types]
     return __atomic64_add_barrier(i, &v->counter) + i;
                                      ^
   In file included from arch/s390/include/asm/bitops.h:38:0,
                    from include/linux/bitops.h:38,
                    from include/linux/kernel.h:11,
                    from arch/s390/include/asm/bug.h:5,
                    from include/linux/bug.h:5,
                    from include/linux/page-flags.h:10,
                    from kernel/bounds.c:10:
   arch/s390/include/asm/atomic_ops.h:35:14: note: expected 'long int *' but argument is of type 'u64 * {aka long long unsigned int *}'
    __ATOMIC_OPS(__atomic64_add, long, "laag")
                 ^
   arch/s390/include/asm/atomic_ops.h:14:23: note: in definition of macro '__ATOMIC_OP'
    static inline op_type op_name(op_type val, op_type *ptr)  \
                          ^~~~~~~
>> arch/s390/include/asm/atomic_ops.h:35:1: note: in expansion of macro '__ATOMIC_OPS'
    __ATOMIC_OPS(__atomic64_add, long, "laag")
    ^~~~~~~~~~~~
   In file included from include/linux/atomic.h:5:0,
                    from include/linux/debug_locks.h:6,
                    from include/linux/lockdep.h:28,
                    from include/linux/spinlock_types.h:18,
                    from kernel/bounds.c:14:
   arch/s390/include/asm/atomic.h: In function 'atomic64_fetch_add':
   arch/s390/include/asm/atomic.h:134:35: error: passing argument 2 of '__atomic64_add_barrier' from incompatible pointer type [-Werror=incompatible-pointer-types]
     return __atomic64_add_barrier(i, &v->counter);
                                      ^
   In file included from arch/s390/include/asm/bitops.h:38:0,
                    from include/linux/bitops.h:38,
                    from include/linux/kernel.h:11,
                    from arch/s390/include/asm/bug.h:5,
                    from include/linux/bug.h:5,
                    from include/linux/page-flags.h:10,
                    from kernel/bounds.c:10:
   arch/s390/include/asm/atomic_ops.h:35:14: note: expected 'long int *' but argument is of type 'u64 * {aka long long unsigned int *}'
    __ATOMIC_OPS(__atomic64_add, long, "laag")
                 ^
   arch/s390/include/asm/atomic_ops.h:14:23: note: in definition of macro '__ATOMIC_OP'
    static inline op_type op_name(op_type val, op_type *ptr)  \
                          ^~~~~~~
>> arch/s390/include/asm/atomic_ops.h:35:1: note: in expansion of macro '__ATOMIC_OPS'
    __ATOMIC_OPS(__atomic64_add, long, "laag")
    ^~~~~~~~~~~~
   In file included from include/linux/atomic.h:5:0,
                    from include/linux/debug_locks.h:6,
                    from include/linux/lockdep.h:28,
                    from include/linux/spinlock_types.h:18,
                    from kernel/bounds.c:14:
   arch/s390/include/asm/atomic.h: In function 'atomic64_add':
>> arch/s390/include/asm/atomic.h:141:27: error: passing argument 2 of '__atomic64_add_const' from incompatible pointer type [-Werror=incompatible-pointer-types]
      __atomic64_add_const(i, &v->counter);
                              ^
   In file included from arch/s390/include/asm/bitops.h:38:0,
                    from include/linux/bitops.h:38,
                    from include/linux/kernel.h:11,
                    from arch/s390/include/asm/bug.h:5,
                    from include/linux/bug.h:5,
                    from include/linux/page-flags.h:10,
                    from kernel/bounds.c:10:
   arch/s390/include/asm/atomic_ops.h:57:20: note: expected 'long int *' but argument is of type 'u64 * {aka long long unsigned int *}'
    __ATOMIC_CONST_OPS(__atomic64_add_const, long, "agsi")
                       ^
   arch/s390/include/asm/atomic_ops.h:44:20: note: in definition of macro '__ATOMIC_CONST_OP'
    static inline void op_name(op_type val, op_type *ptr)   \
                       ^~~~~~~
>> arch/s390/include/asm/atomic_ops.h:57:1: note: in expansion of macro '__ATOMIC_CONST_OPS'
    __ATOMIC_CONST_OPS(__atomic64_add_const, long, "agsi")
    ^~~~~~~~~~~~~~~~~~
   In file included from include/linux/atomic.h:5:0,
                    from include/linux/debug_locks.h:6,
                    from include/linux/lockdep.h:28,
                    from include/linux/spinlock_types.h:18,
                    from kernel/bounds.c:14:
>> arch/s390/include/asm/atomic.h:145:20: error: passing argument 2 of '__atomic64_add' from incompatible pointer type [-Werror=incompatible-pointer-types]
     __atomic64_add(i, &v->counter);
                       ^
   In file included from arch/s390/include/asm/bitops.h:38:0,
                    from include/linux/bitops.h:38,
                    from include/linux/kernel.h:11,
                    from arch/s390/include/asm/bug.h:5,
                    from include/linux/bug.h:5,
                    from include/linux/page-flags.h:10,
                    from kernel/bounds.c:10:
   arch/s390/include/asm/atomic_ops.h:35:14: note: expected 'long int *' but argument is of type 'u64 * {aka long long unsigned int *}'
    __ATOMIC_OPS(__atomic64_add, long, "laag")
                 ^
   arch/s390/include/asm/atomic_ops.h:14:23: note: in definition of macro '__ATOMIC_OP'
    static inline op_type op_name(op_type val, op_type *ptr)  \
                          ^~~~~~~
>> arch/s390/include/asm/atomic_ops.h:35:1: note: in expansion of macro '__ATOMIC_OPS'
    __ATOMIC_OPS(__atomic64_add, long, "laag")
    ^~~~~~~~~~~~
   In file included from include/linux/atomic.h:5:0,
                    from include/linux/debug_locks.h:6,
                    from include/linux/lockdep.h:28,
                    from include/linux/spinlock_types.h:18,
                    from kernel/bounds.c:14:
   arch/s390/include/asm/atomic.h: In function 'atomic64_cmpxchg':
>> arch/s390/include/asm/atomic.h:152:28: error: passing argument 1 of '__atomic64_cmpxchg' from incompatible pointer type [-Werror=incompatible-pointer-types]
     return __atomic64_cmpxchg(&v->counter, old, new);
                               ^
   In file included from arch/s390/include/asm/bitops.h:38:0,
                    from include/linux/bitops.h:38,
                    from include/linux/kernel.h:11,
                    from arch/s390/include/asm/bug.h:5,
                    from include/linux/bug.h:5,
                    from include/linux/page-flags.h:10,
                    from kernel/bounds.c:10:
   arch/s390/include/asm/atomic_ops.h:133:20: note: expected 'long int *' but argument is of type 'u64 * {aka long long unsigned int *}'
    static inline long __atomic64_cmpxchg(long *ptr, long old, long new)
                       ^~~~~~~~~~~~~~~~~~
   In file included from include/linux/atomic.h:5:0,
                    from include/linux/debug_locks.h:6,
                    from include/linux/lockdep.h:28,
                    from include/linux/spinlock_types.h:18,
                    from kernel/bounds.c:14:
   arch/s390/include/asm/atomic.h: In function 'atomic64_and':
>> arch/s390/include/asm/atomic.h:158:21: error: passing argument 2 of '__atomic64_and' from incompatible pointer type [-Werror=incompatible-pointer-types]
     __atomic64_##op(i, &v->counter);    \
                        ^
>> arch/s390/include/asm/atomic.h:165:1: note: in expansion of macro 'ATOMIC64_OPS'
    ATOMIC64_OPS(and)
    ^~~~~~~~~~~~
   In file included from arch/s390/include/asm/bitops.h:38:0,
                    from include/linux/bitops.h:38,
                    from include/linux/kernel.h:11,
                    from arch/s390/include/asm/bug.h:5,
                    from include/linux/bug.h:5,
                    from include/linux/page-flags.h:10,
                    from kernel/bounds.c:10:
   arch/s390/include/asm/atomic_ops.h:36:14: note: expected 'long int *' but argument is of type 'u64 * {aka long long unsigned int *}'
    __ATOMIC_OPS(__atomic64_and, long, "lang")
                 ^
   arch/s390/include/asm/atomic_ops.h:14:23: note: in definition of macro '__ATOMIC_OP'
    static inline op_type op_name(op_type val, op_type *ptr)  \
                          ^~~~~~~
   arch/s390/include/asm/atomic_ops.h:36:1: note: in expansion of macro '__ATOMIC_OPS'
    __ATOMIC_OPS(__atomic64_and, long, "lang")
    ^~~~~~~~~~~~
   In file included from include/linux/atomic.h:5:0,
                    from include/linux/debug_locks.h:6,
                    from include/linux/lockdep.h:28,
                    from include/linux/spinlock_types.h:18,
                    from kernel/bounds.c:14:
   arch/s390/include/asm/atomic.h: In function 'atomic64_fetch_and':
>> arch/s390/include/asm/atomic.h:162:38: error: passing argument 2 of '__atomic64_and_barrier' from incompatible pointer type [-Werror=incompatible-pointer-types]
     return __atomic64_##op##_barrier(i, &v->counter);  \
                                         ^
>> arch/s390/include/asm/atomic.h:165:1: note: in expansion of macro 'ATOMIC64_OPS'
    ATOMIC64_OPS(and)
    ^~~~~~~~~~~~
   In file included from arch/s390/include/asm/bitops.h:38:0,
                    from include/linux/bitops.h:38,
                    from include/linux/kernel.h:11,
                    from arch/s390/include/asm/bug.h:5,
                    from include/linux/bug.h:5,
                    from include/linux/page-flags.h:10,
                    from kernel/bounds.c:10:
   arch/s390/include/asm/atomic_ops.h:36:14: note: expected 'long int *' but argument is of type 'u64 * {aka long long unsigned int *}'
    __ATOMIC_OPS(__atomic64_and, long, "lang")
                 ^
   arch/s390/include/asm/atomic_ops.h:14:23: note: in definition of macro '__ATOMIC_OP'
    static inline op_type op_name(op_type val, op_type *ptr)  \
                          ^~~~~~~
   arch/s390/include/asm/atomic_ops.h:36:1: note: in expansion of macro '__ATOMIC_OPS'
    __ATOMIC_OPS(__atomic64_and, long, "lang")
    ^~~~~~~~~~~~
   In file included from include/linux/atomic.h:5:0,
                    from include/linux/debug_locks.h:6,
                    from include/linux/lockdep.h:28,
                    from include/linux/spinlock_types.h:18,
                    from kernel/bounds.c:14:
   arch/s390/include/asm/atomic.h: In function 'atomic64_or':
>> arch/s390/include/asm/atomic.h:158:21: error: passing argument 2 of '__atomic64_or' from incompatible pointer type [-Werror=incompatible-pointer-types]
     __atomic64_##op(i, &v->counter);    \
                        ^
   arch/s390/include/asm/atomic.h:166:1: note: in expansion of macro 'ATOMIC64_OPS'
    ATOMIC64_OPS(or)
    ^~~~~~~~~~~~
   In file included from arch/s390/include/asm/bitops.h:38:0,
                    from include/linux/bitops.h:38,
                    from include/linux/kernel.h:11,
                    from arch/s390/include/asm/bug.h:5,
                    from include/linux/bug.h:5,
                    from include/linux/page-flags.h:10,
                    from kernel/bounds.c:10:
   arch/s390/include/asm/atomic_ops.h:37:14: note: expected 'long int *' but argument is of type 'u64 * {aka long long unsigned int *}'
    __ATOMIC_OPS(__atomic64_or,  long, "laog")
                 ^
   arch/s390/include/asm/atomic_ops.h:14:23: note: in definition of macro '__ATOMIC_OP'
    static inline op_type op_name(op_type val, op_type *ptr)  \
                          ^~~~~~~
   arch/s390/include/asm/atomic_ops.h:37:1: note: in expansion of macro '__ATOMIC_OPS'
    __ATOMIC_OPS(__atomic64_or,  long, "laog")
    ^~~~~~~~~~~~
   In file included from include/linux/atomic.h:5:0,
                    from include/linux/debug_locks.h:6,
                    from include/linux/lockdep.h:28,
                    from include/linux/spinlock_types.h:18,
                    from kernel/bounds.c:14:
   arch/s390/include/asm/atomic.h: In function 'atomic64_fetch_or':
>> arch/s390/include/asm/atomic.h:162:38: error: passing argument 2 of '__atomic64_or_barrier' from incompatible pointer type [-Werror=incompatible-pointer-types]
     return __atomic64_##op##_barrier(i, &v->counter);  \
                                         ^
   arch/s390/include/asm/atomic.h:166:1: note: in expansion of macro 'ATOMIC64_OPS'
    ATOMIC64_OPS(or)
    ^~~~~~~~~~~~
   In file included from arch/s390/include/asm/bitops.h:38:0,
                    from include/linux/bitops.h:38,
                    from include/linux/kernel.h:11,
                    from arch/s390/include/asm/bug.h:5,
                    from include/linux/bug.h:5,
                    from include/linux/page-flags.h:10,
                    from kernel/bounds.c:10:
   arch/s390/include/asm/atomic_ops.h:37:14: note: expected 'long int *' but argument is of type 'u64 * {aka long long unsigned int *}'
    __ATOMIC_OPS(__atomic64_or,  long, "laog")
                 ^
   arch/s390/include/asm/atomic_ops.h:14:23: note: in definition of macro '__ATOMIC_OP'
    static inline op_type op_name(op_type val, op_type *ptr)  \
                          ^~~~~~~
   arch/s390/include/asm/atomic_ops.h:37:1: note: in expansion of macro '__ATOMIC_OPS'
    __ATOMIC_OPS(__atomic64_or,  long, "laog")
    ^~~~~~~~~~~~
   In file included from include/linux/atomic.h:5:0,
                    from include/linux/debug_locks.h:6,
                    from include/linux/lockdep.h:28,
                    from include/linux/spinlock_types.h:18,
                    from kernel/bounds.c:14:
   arch/s390/include/asm/atomic.h: In function 'atomic64_xor':
>> arch/s390/include/asm/atomic.h:158:21: error: passing argument 2 of '__atomic64_xor' from incompatible pointer type [-Werror=incompatible-pointer-types]
     __atomic64_##op(i, &v->counter);    \
                        ^
   arch/s390/include/asm/atomic.h:167:1: note: in expansion of macro 'ATOMIC64_OPS'
    ATOMIC64_OPS(xor)
    ^~~~~~~~~~~~
   In file included from arch/s390/include/asm/bitops.h:38:0,
                    from include/linux/bitops.h:38,
                    from include/linux/kernel.h:11,
                    from arch/s390/include/asm/bug.h:5,
                    from include/linux/bug.h:5,
                    from include/linux/page-flags.h:10,
                    from kernel/bounds.c:10:
   arch/s390/include/asm/atomic_ops.h:38:14: note: expected 'long int *' but argument is of type 'u64 * {aka long long unsigned int *}'
    __ATOMIC_OPS(__atomic64_xor, long, "laxg")
                 ^
   arch/s390/include/asm/atomic_ops.h:14:23: note: in definition of macro '__ATOMIC_OP'
    static inline op_type op_name(op_type val, op_type *ptr)  \
                          ^~~~~~~
   arch/s390/include/asm/atomic_ops.h:38:1: note: in expansion of macro '__ATOMIC_OPS'
    __ATOMIC_OPS(__atomic64_xor, long, "laxg")
    ^~~~~~~~~~~~
   In file included from include/linux/atomic.h:5:0,
                    from include/linux/debug_locks.h:6,
                    from include/linux/lockdep.h:28,
                    from include/linux/spinlock_types.h:18,
                    from kernel/bounds.c:14:
   arch/s390/include/asm/atomic.h: In function 'atomic64_fetch_xor':
>> arch/s390/include/asm/atomic.h:162:38: error: passing argument 2 of '__atomic64_xor_barrier' from incompatible pointer type [-Werror=incompatible-pointer-types]
     return __atomic64_##op##_barrier(i, &v->counter);  \
                                         ^
   arch/s390/include/asm/atomic.h:167:1: note: in expansion of macro 'ATOMIC64_OPS'
    ATOMIC64_OPS(xor)
    ^~~~~~~~~~~~
   In file included from arch/s390/include/asm/bitops.h:38:0,
                    from include/linux/bitops.h:38,
                    from include/linux/kernel.h:11,
                    from arch/s390/include/asm/bug.h:5,
                    from include/linux/bug.h:5,
                    from include/linux/page-flags.h:10,
                    from kernel/bounds.c:10:
   arch/s390/include/asm/atomic_ops.h:38:14: note: expected 'long int *' but argument is of type 'u64 * {aka long long unsigned int *}'
    __ATOMIC_OPS(__atomic64_xor, long, "laxg")
                 ^
   arch/s390/include/asm/atomic_ops.h:14:23: note: in definition of macro '__ATOMIC_OP'
    static inline op_type op_name(op_type val, op_type *ptr)  \
                          ^~~~~~~
   arch/s390/include/asm/atomic_ops.h:38:1: note: in expansion of macro '__ATOMIC_OPS'
    __ATOMIC_OPS(__atomic64_xor, long, "laxg")
    ^~~~~~~~~~~~
   cc1: some warnings being treated as errors
   make[2]: *** [kernel/bounds.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +/__atomic64_add_barrier +129 arch/s390/include/asm/atomic.h

^1da177e include/asm-s390/atomic.h      Linus Torvalds     2005-04-16  126  
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11  127  static inline long atomic64_add_return(long i, atomic64_t *v)
^1da177e include/asm-s390/atomic.h      Linus Torvalds     2005-04-16  128  {
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11 @129  	return __atomic64_add_barrier(i, &v->counter) + i;
0ccc8b7a arch/s390/include/asm/atomic.h Heiko Carstens     2014-03-20  130  }
0ccc8b7a arch/s390/include/asm/atomic.h Heiko Carstens     2014-03-20  131  
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11  132  static inline long atomic64_fetch_add(long i, atomic64_t *v)
56fefbbc arch/s390/include/asm/atomic.h Peter Zijlstra     2016-04-18  133  {
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11  134  	return __atomic64_add_barrier(i, &v->counter);
56fefbbc arch/s390/include/asm/atomic.h Peter Zijlstra     2016-04-18  135  }
56fefbbc arch/s390/include/asm/atomic.h Peter Zijlstra     2016-04-18  136  
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11  137  static inline void atomic64_add(long i, atomic64_t *v)
0ccc8b7a arch/s390/include/asm/atomic.h Heiko Carstens     2014-03-20  138  {
0ccc8b7a arch/s390/include/asm/atomic.h Heiko Carstens     2014-03-20  139  #ifdef CONFIG_HAVE_MARCH_Z196_FEATURES
0ccc8b7a arch/s390/include/asm/atomic.h Heiko Carstens     2014-03-20  140  	if (__builtin_constant_p(i) && (i > -129) && (i < 128)) {
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11 @141  		__atomic64_add_const(i, &v->counter);
0ccc8b7a arch/s390/include/asm/atomic.h Heiko Carstens     2014-03-20  142  		return;
0ccc8b7a arch/s390/include/asm/atomic.h Heiko Carstens     2014-03-20  143  	}
0ccc8b7a arch/s390/include/asm/atomic.h Heiko Carstens     2014-03-20  144  #endif
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11 @145  	__atomic64_add(i, &v->counter);
^1da177e include/asm-s390/atomic.h      Linus Torvalds     2005-04-16  146  }
973bd993 include/asm-s390/atomic.h      Martin Schwidefsky 2006-01-06  147  
3a5f10e3 include/asm-s390/atomic.h      Mathieu Desnoyers  2007-02-21  148  #define atomic64_xchg(v, new) (xchg(&((v)->counter), new))
3a5f10e3 include/asm-s390/atomic.h      Mathieu Desnoyers  2007-02-21  149  
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11  150  static inline long atomic64_cmpxchg(atomic64_t *v, long old, long new)
973bd993 include/asm-s390/atomic.h      Martin Schwidefsky 2006-01-06  151  {
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11 @152  	return __atomic64_cmpxchg(&v->counter, old, new);
973bd993 include/asm-s390/atomic.h      Martin Schwidefsky 2006-01-06  153  }
^1da177e include/asm-s390/atomic.h      Linus Torvalds     2005-04-16  154  
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11  155  #define ATOMIC64_OPS(op)						\
ae8c35c8 arch/s390/include/asm/atomic.h Peter Zijlstra     2014-04-23  156  static inline void atomic64_##op(long i, atomic64_t *v)			\
ae8c35c8 arch/s390/include/asm/atomic.h Peter Zijlstra     2014-04-23  157  {									\
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11 @158  	__atomic64_##op(i, &v->counter);				\
56fefbbc arch/s390/include/asm/atomic.h Peter Zijlstra     2016-04-18  159  }									\
56fefbbc arch/s390/include/asm/atomic.h Peter Zijlstra     2016-04-18  160  static inline long atomic64_fetch_##op(long i, atomic64_t *v)		\
56fefbbc arch/s390/include/asm/atomic.h Peter Zijlstra     2016-04-18  161  {									\
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11 @162  	return __atomic64_##op##_barrier(i, &v->counter);		\
ae8c35c8 arch/s390/include/asm/atomic.h Peter Zijlstra     2014-04-23  163  }
ae8c35c8 arch/s390/include/asm/atomic.h Peter Zijlstra     2014-04-23  164  
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11 @165  ATOMIC64_OPS(and)
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11  166  ATOMIC64_OPS(or)
126b30c3 arch/s390/include/asm/atomic.h Martin Schwidefsky 2016-11-11  167  ATOMIC64_OPS(xor)
ae8c35c8 arch/s390/include/asm/atomic.h Peter Zijlstra     2014-04-23  168  

:::::: The code at line 129 was first introduced by commit
:::::: 126b30c3cb476ce68489a657a7defb8e73775e6f s390/atomic: refactor atomic primitives

:::::: TO: Martin Schwidefsky <schwidefsky@de.ibm.com>
:::::: CC: Martin Schwidefsky <schwidefsky@de.ibm.com>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 50353 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2018-07-09 18:06 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-09 12:47 [PATCH] atomic{64}_t: Explicitly specify data storage length and alignment Alexey Brodkin
2018-07-09 12:55 ` Geert Uytterhoeven
2018-07-09 13:07 ` Will Deacon
2018-07-09 13:30 ` David Laight
2018-07-09 13:49   ` Geert Uytterhoeven
2018-07-09 13:35 ` Peter Zijlstra
2018-07-09 14:30   ` Alexey Brodkin
2018-07-09 14:45     ` Peter Zijlstra
2018-07-09 14:04 ` Russell King - ARM Linux
2018-07-09 16:25 ` kbuild test robot
2018-07-09 18:05 ` kbuild test robot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).