kernel.git/arch/s390/include/asm/atomic.h, branch linux-5.18.y

locking/atomic: make ARCH_ATOMIC a Kconfig symbol

2021-05-26T11:20:49Z

Subsequent patches will move architectures over to the ARCH_ATOMIC API, after preparing the asm-generic atomic implementations to function with or without ARCH_ATOMIC. As some architectures use the asm-generic implementations exclusively (and don't have a local atomic.h), and to avoid the risk that ARCH_ATOMIC isn't defined in some cases we expect, let's make the ARCH_ATOMIC macro a Kconfig symbol instead, so that we can guarantee it is consistently available where needed. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland Cc: Boqun Feng Cc: Peter Zijlstra Cc: Will Deacon Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20210525140232.53872-2-mark.rutland@arm.com

s390/atomic,cmpxchg: switch to use atomic-instrumented.h

2021-04-12T10:46:43Z

Add arch_ prefix to all atomic operations, and define ARCH_ATOMIC. This enables KASAN instrumentation for all atomic operations on s390. This is the s390 variant of commit 8bf705d13039 ("locking/atomic/x86: Switch atomic.h to use atomic-instrumented.h"). Signed-off-by: Heiko Carstens

s390/atomic: move remaining inline assemblies to atomic_ops.h

2021-04-12T10:46:42Z

Move all remaining inline assemblies from atomic.h to atomic_ops.h. That way all atomic inline assemblies are contained within only a single header file. Signed-off-by: Heiko Carstens

s390/atomic: remove small optimization to fix clang build

2021-01-19T11:29:26Z

With commit f0cbd3b83ed4 ("s390/atomic: circumvent gcc 10 build regression") there was an attempt to workaroud a gcc build bug, however with the workaround a similar problem with clang appeared. It was recommended to use a workaround which would fail again with gcc. Therefore simply remove the optimization. It is just not worth the effort. Besides that all of this will be changed to use compiler atomic builtins instead anyway. See https://reviews.llvm.org/D90231 and https://reviews.llvm.org/D91786 Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik

s390/atomic: circumvent gcc 10 build regression

2020-08-11T16:16:08Z

Circumvent the following gcc 10 allyesconfig build regression: CC drivers/leds/trigger/ledtrig-cpu.o In file included from ./arch/s390/include/asm/bitops.h:39, from ./include/linux/bitops.h:29, from ./include/linux/kernel.h:12, from drivers/leds/trigger/ledtrig-cpu.c:18: ./arch/s390/include/asm/atomic_ops.h: In function 'ledtrig_cpu': ./arch/s390/include/asm/atomic_ops.h:46:2: warning: 'asm' operand 1 probably does not match constraints 46 | asm volatile( \ | ^~~ ./arch/s390/include/asm/atomic_ops.h:53:2: note: in expansion of macro '__ATOMIC_CONST_OP' 53 | __ATOMIC_CONST_OP(op_name, op_type, op_string, "\n") \ | ^~~~~~~~~~~~~~~~~ ./arch/s390/include/asm/atomic_ops.h:56:1: note: in expansion of macro '__ATOMIC_CONST_OPS' 56 | __ATOMIC_CONST_OPS(__atomic_add_const, int, "asi") | ^~~~~~~~~~~~~~~~~~ ./arch/s390/include/asm/atomic_ops.h:46:2: error: impossible constraint in 'asm' 46 | asm volatile( \ | ^~~ ./arch/s390/include/asm/atomic_ops.h:53:2: note: in expansion of macro '__ATOMIC_CONST_OP' 53 | __ATOMIC_CONST_OP(op_name, op_type, op_string, "\n") \ | ^~~~~~~~~~~~~~~~~ ./arch/s390/include/asm/atomic_ops.h:56:1: note: in expansion of macro '__ATOMIC_CONST_OPS' 56 | __ATOMIC_CONST_OPS(__atomic_add_const, int, "asi") | ^~~~~~~~~~~~~~~~~~ scripts/Makefile.build:280: recipe for target 'drivers/leds/trigger/ledtrig-cpu.o' failed By swapping conditions as proposed here: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549318.html Suggested-by: Ilya Leoshkevich Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens

locking/atomic: Move ATOMIC_INIT into linux/types.h

2020-07-29T14:14:18Z

This patch moves ATOMIC_INIT from asm/atomic.h into linux/types.h. This allows users of atomic_t to use ATOMIC_INIT without having to include atomic.h as that way may lead to header loops. Signed-off-by: Herbert Xu Signed-off-by: Peter Zijlstra (Intel) Acked-by: Waiman Long Link: https://lkml.kernel.org/r/20200729123105.GB7047@gondor.apana.org.au

locking/atomic, s390: Use s64 for atomic64

2019-06-03T10:32:56Z

As a step towards making the atomic64 API use consistent types treewide, let's have the s390 atomic64 implementation use s64 as the underlying type for atomic64_t, rather than long, matching the generated headers. As atomic64_read() depends on the generic defintion of atomic64_t, this still returns long. This will be converted in a subsequent patch. The s390-internal __atomic64_*() ops are also used by the s390 bitops, and expect pointers to long. Since atomic64_t::counter will be converted to s64 in a subsequent patch, pointes to this are explicitly cast to pointers to long when passed to __atomic64_*() ops. Otherwise, there should be no functional change as a result of this patch. Signed-off-by: Mark Rutland Signed-off-by: Peter Zijlstra (Intel) Cc: Heiko Carstens Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: aou@eecs.berkeley.edu Cc: arnd@arndb.de Cc: bp@alien8.de Cc: catalin.marinas@arm.com Cc: davem@davemloft.net Cc: fenghua.yu@intel.com Cc: herbert@gondor.apana.org.au Cc: ink@jurassic.park.msu.ru Cc: jhogan@kernel.org Cc: linux@armlinux.org.uk Cc: mattst88@gmail.com Cc: mpe@ellerman.id.au Cc: palmer@sifive.com Cc: paul.burton@mips.com Cc: paulus@samba.org Cc: ralf@linux-mips.org Cc: rth@twiddle.net Cc: tony.luck@intel.com Cc: vgupta@synopsys.com Link: https://lkml.kernel.org/r/20190522132250.26499-14-mark.rutland@arm.com Signed-off-by: Ingo Molnar

atomics/treewide: Make conditional inc/dec ops optional

2018-06-21T12:25:24Z

The conditional inc/dec ops differ for atomic_t and atomic64_t: - atomic_inc_unless_positive() is optional for atomic_t, and doesn't exist for atomic64_t. - atomic_dec_unless_negative() is optional for atomic_t, and doesn't exist for atomic64_t. - atomic_dec_if_positive is optional for atomic_t, and is mandatory for atomic64_t. Let's make these consistently optional for both. At the same time, let's clean up the existing fallbacks to use atomic_try_cmpxchg(). The instrumented atomics are updated accordingly. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland Reviewed-by: Will Deacon Acked-by: Peter Zijlstra (Intel) Cc: Boqun Feng Cc: Linus Torvalds Cc: Thomas Gleixner Link: https://lore.kernel.org/lkml/20180621121321.4761-18-mark.rutland@arm.com Signed-off-by: Ingo Molnar

atomics/treewide: Make unconditional inc/dec ops optional

2018-06-21T12:25:24Z

Many of the inc/dec ops are mandatory, but for most architectures inc/dec are simply trivial wrappers around their corresponding add/sub ops. Let's make all the inc/dec ops optional, so that we can get rid of these boilerplate wrappers. The instrumented atomics are updated accordingly. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland Reviewed-by: Will Deacon Acked-by: Peter Zijlstra (Intel) Acked-by: Palmer Dabbelt Cc: Boqun Feng Cc: Linus Torvalds Cc: Thomas Gleixner Link: https://lore.kernel.org/lkml/20180621121321.4761-17-mark.rutland@arm.com Signed-off-by: Ingo Molnar

atomics/treewide: Make test ops optional

2018-06-21T12:25:24Z

Some of the atomics return the result of a test applied after the atomic operation, and almost all architectures implement these as trivial wrappers around the underlying atomic. Specifically: * _inc_and_test(v) is (_inc_return(v) == 0) * _dec_and_test(v) is (_dec_return(v) == 0) * _sub_and_test(i, v) is (_sub_return(i, v) == 0) * _add_negative(i, v) is (_add_return(i, v) < 0) Rather than have these definitions duplicated in all architectures, with minor inconsistencies in formatting and documentation, let's make these operations optional, with default fallbacks as above. Implementations must now provide a preprocessor symbol. The instrumented atomics are updated accordingly. Both x86 and m68k have custom implementations, which are left as-is, given preprocessor symbols to avoid being overridden. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland Reviewed-by: Will Deacon Acked-by: Geert Uytterhoeven Acked-by: Peter Zijlstra (Intel) Acked-by: Palmer Dabbelt Cc: Boqun Feng Cc: Linus Torvalds Cc: Thomas Gleixner Link: https://lore.kernel.org/lkml/20180621121321.4761-16-mark.rutland@arm.com Signed-off-by: Ingo Molnar