- Jun 22, 2021
-
-
André Almeida authored
Add testing for futex_cmp_requeue(). The first test just requeues from one waiter to another one, and wakes it. The second performs both wake and requeue, and checks the return values to see if the operation woke/requeued the expected number of waiters. Signed-off-by:
André Almeida <andrealmeid@collabora.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Davidlohr Bueso <dbueso@suse.de> Link: https://lore.kernel.org/r/20210531165036.41468-3-andrealmeid@collabora.com
-
André Almeida authored
There are three different strategies to uniquely identify a futex in the kernel: - Private futexes: uses the pointer to mm_struct and the page address - Shared futexes: checks if the page containing the address is a PageAnon: - If it is, uses the same data as a private futexes - If it isn't, uses an inode sequence number from struct inode and the page's index Create a selftest to check those three paths and basic wait/wake mechanism. Signed-off-by:
-
- Jun 09, 2021
-
-
Huilong Deng authored
Macros should not use a trailing semicolon. Signed-off-by:
Huilong Deng <denghuilong@cdjrlc.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20210605045302.37154-1-denghuilong@cdjrlc.com
-
- May 31, 2021
-
-
Randy Dunlap authored
Some arches (um, sparc64, riscv, xtensa) cause a Kconfig warning for LOCKDEP. These arch-es select LOCKDEP_SUPPORT but they are not listed as one of the arch-es that LOCKDEP depends on. Since (16) arch-es define the Kconfig symbol LOCKDEP_SUPPORT if they intend to have LOCKDEP support, replace the awkward list of arch-es that LOCKDEP depends on with the LOCKDEP_SUPPORT symbol. But wait. LOCKDEP_SUPPORT is included in LOCK_DEBUGGING_SUPPORT, which is already a dependency here, so LOCKDEP_SUPPORT is redundant and not needed. That leaves the FRAME_POINTER dependency, but it is part of an expression like this: depends on (A && B) && (FRAME_POINTER || B') where B' is a dependency of B so if B is true then B' is true and the value of FRAME_POINTER does not matter. Thus we can also delete the FRAME_POINTER dependency. Fixes this kconfig warning: (for um, sparc64, riscv, xtensa) WARNING: unmet direct dependencies detected for LOCKDEP Depends on [n]: DEBUG_KERNEL [=y] && LOCK_DEBUGGING_SUPPORT [=y] && (FRAME_POINTER [=n] || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86) Selected by [y]: - PROVE_LOCKING [=y] && DEBUG_KERNEL [=y] && LOCK_DEBUGGING_SUPPORT [=y] - LOCK_STAT [=y] && DEBUG_KERNEL [=y] && LOCK_DEBUGGING_SUPPORT [=y] - DEBUG_LOCK_ALLOC [=y] && DEBUG_KERNEL [=y] && LOCK_DEBUGGING_SUPPORT [=y] Fixes: 7d37cb2c ("lib: fix kconfig dependency on ARCH_WANT_FRAME_POINTERS") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Waiman Long <longman@redhat.com> Link: https://lkml.kernel.org/r/20210524224150.8009-1-rdunlap@infradead.org
-
Xiongwei Song authored
The block condition matrix is using 'E' as the writer notation, however, the writer reminder below the matrix is using 'W', to make them consistent and make the matrix more readable, we'd better to use 'W' to represent writer. Suggested-by:
Waiman Long <llong@redhat.com> Suggested-by:
Boqun Feng <boqun.feng@gmail.com> Signed-off-by:
Xiongwei Song <sxwjean@gmail.com> Signed-off-by:
-
- May 26, 2021
-
-
Mark Rutland authored
Now that all architectures implement ARCH_ATOMIC, the fallbacks are generated before the instrumented wrappers are generated. Due to this, in atomic-instrumented.h we can assume that the whole set of atomic functions has been generated. Likewise, atomic-instrumented.h doesn't need to provide a preprocessor definition for every atomic it wraps. This patch removes the redundant ifdeffery. There should be no functional change as a result of this patch. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Signed-off-by:
-
Mark Rutland authored
Now that all architectures implement ARCH_ATOMIC, we can make it mandatory, removing the Kconfig symbol and logic for !ARCH_ATOMIC. There should be no functional change as a result of this patch. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Signed-off-by:
-
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates xtensa to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. Signed-off-by:Max Filippov <jcmvbkbc@gmail.com> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Chris Zankel <chris@zankel.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Signed-off-by:
-
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates sparc to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. Signed-off-by: -
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates sh to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. Signed-off-by: -
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates riscv to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. Signed-off-by:Palmer Dabbelt <palmerdabbelt@google.com> Acked-by:
-
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates powerpc to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. While atomic_try_cmpxchg_lock() is not part of the common atomic API, it is given an `arch_` prefix for consistency. Signed-off-by: -
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates parisc to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. Signed-off-by: -
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates openrisc to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. Signed-off-by:Stafford Horne <shorne@gmail.com> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Jonas Bonn <jonas@southpole.se> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Cc: Will Deacon <will@kernel.org> Signed-off-by:
-
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates nios2 to ARCH_ATOMIC, using the asm-generic implementations. Signed-off-by:
-
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates nds32 to ARCH_ATOMIC, using the asm-generic implementations. Signed-off-by:
-
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates mips to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. Signed-off-by: -
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates microblaze to ARCH_ATOMIC, using the asm-generic implementations. Signed-off-by:
-
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates m68k to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. While atomic_dec_and_test_lt() is not part of the common atomic API, it is also given an `arch_` prefix for consistency. Signed-off-by:Greg Ungerer <gerg@linux-m68k.org> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Signed-off-by:
-
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates ia64 to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. Signed-off-by: -
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates hexagon to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. Signed-off-by: -
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates h8300 to ARCH_ATOMIC, using the asm-generic implementations. Signed-off-by:
-
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates csky to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. Signed-off-by:Guo Ren <guoren@kernel.org> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Signed-off-by:
-
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates alpha to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. Signed-off-by: -
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates alpha to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. Signed-off-by:Vineet Gupta <vgupta@synopsys.com> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Signed-off-by:
-
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as once all architectures are converted it will be possible to make significant cleanups to the atomics headers, and this will make it much easier to generically enable atomic functionality (e.g. debug logic in the instrumented wrappers). As a step towards that, this patch migrates alpha to ARCH_ATOMIC. The arch code provides arch_{atomic,atomic64,xchg,cmpxchg}*(), and common code wraps these with optional instrumentation to provide the regular functions. Note: xchg_local() is NOT currently part of the generic atomic arch_atomic API, and is not instrumented. Signed-off-by: -
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as this will enable functionality, and once all architectures are converted it will be possible to make significant cleanups to the atomic headers. A number of architectures use asm-generic/cmpxchg.h or asm-generic/cmpxhg-local.h, and it's impractical to convert the headers and all these architectures in one go. To make it possible to convert them one-by-one, let's make the asm-generic implementation function as either cmpxchg*() or arch_cmpxchg*() depending on whether ARCH_ATOMIC is selected. To do this, the generic implementations are prefixed as generic_cmpxchg_*(), and preprocessor definitions map cmpxchg_*()/arch_cmpxchg_*() onto these as appropriate. Once all users are moved over to ARCH_ATOMIC the ifdeffery in the header can be simplified and/or removed entirely. For existing users (none of which select ARCH_ATOMIC), there should be no functional change as a result of this patch. Signed-off-by:
-
Mark Rutland authored
The asm-generic implementations of cmpxchg_local() and cmpxchg64_local() use a `_generic` suffix to distinguish themselves from arch code or wrappers used elsewhere. Subsequent patches will add ARCH_ATOMIC support to these implementations, and will distinguish more functions with a `generic` portion. To align with how ARCH_ATOMIC uses an `arch_` prefix, it would be helpful to use a `generic_` prefix rather than a `_generic` suffix. In preparation for this, this patch renames the existing functions to make `generic` a prefix rather than a suffix. There should be no functional change as a result of this patch. Signed-off-by:
-
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as this will enable functionality, and once all architectures are converted it will be possible to make significant cleanups to the atomic headers. A number of architectures use asm-generic/atomic64.h, and it's impractical to convert the header and all these architectures in one go. To make it possible to convert them one-by-one, let's make the asm-generic implementation function as either atomic64_*() or arch_atomic64_*() depending on whether ARCH_ATOMIC is selected. To do this, the generic implementations are prefixed as generic_atomic64_*(), and preprocessor definitions map atomic64_*()/arch_atomic64_*() onto these as appropriate. Once all users are moved over to ARCH_ATOMIC the ifdeffery in the header can be simplified and/or removed entirely. For existing users (none of which select ARCH_ATOMIC), there should be no functional change as a result of this patch. Signed-off-by:
-
Mark Rutland authored
We'd like all architectures to convert to ARCH_ATOMIC, as this will enable functionality, and once all architectures are converted it will be possible to make significant cleanups to the atomic headers. A number of architectures use asm-generic/atomic.h, and it's impractical to convert the header and all these architectures in one go. To make it possible to convert them one-by-one, let's make the asm-generic implementation function as either atomic_*() or arch_atomic_*() depending on whether ARCH_ATOMIC is selected. To do this, the C implementations are prefixed as generic_atomic_*(), and preprocessor definitions map atomic_*()/arch_atomic_*() onto these as appropriate. Once all users are moved over to ARCH_ATOMIC the ifdeffery in the header can be simplified and/or removed entirely. For existing users (none of which select ARCH_ATOMIC), there should be no functional change as a result of this patch. Signed-off-by:
-
Mark Rutland authored
Now that asm-generic/atomic.h is only used by architectures without any architecture-specific atomic definitions, we know that there will be no architecture-specific implementations to override, and can remove the ifdeffery this has previously required, bringing it into line with asm-generic/atomic64.h. At the same time, we can implement atomic_add() and atomic_sub() directly using ATOMIC_OP(), since we know architectures won't provide atomic_add_return() or atomic_sub_return(). There should be no functional change as a result of this patch. Signed-off-by:
-
Mark Rutland authored
Since commit: 560cb12a ("locking,arch: Rewrite generic atomic support") ... we conditionally include <linux/irqflags.h> before defining atomics using locking, and hence do not need to do so unconditionally later in the header. This patch removes the redundant include. Signed-off-by:
-
Mark Rutland authored
The commentary in asm-generic/atomic.h is stale; let's bring it up-to date: * The block comment at the start of the file mentions this is only usable on UP systems, but is immediately followed by an SMP implementation using cmpxchg. Let's delete the misleading statement. * A comment near the end of the file was originally at the top of the file, but over time rework has shuffled it near the end, and it's long been superceded by the block comment at the top of the file. Let's remove it. * Since asm-generic/atomic.h isn't the canonical documentation for the atomic ops, and since the existing comments are not in kerneldoc format, we don't need to document the semantics of each operation here (and this would be better done in a centralised document). Let's remove these comments. Signed-off-by:
-
Mark Rutland authored
OpenRISC is the only architecture which uses asm-generic/atomic.h and also provides its own implementation of some functions, requiring ifdeferry in the asm-generic header. As OpenRISC provides the vast majority of functions itself, it would be simpler overall if it also provided the few functions it cribs from asm-generic. This patch decouples OpenRISC from asm-generic/atomic.h. Subsequent patches will simplify the asm-generic implementation and remove the now unnecessary ifdeferry. There should be no functional change as a result of this patch. Signed-off-by:
-
Mark Rutland authored
Microblaze provides its own implementation of atomic_dec_if_positive(), but nothing else. For a while now, the conditional inc/dec ops have been optional, and the core code will provide generic implementations using the code templates in scripts/atomic/fallbacks/. For simplicity, and for consistency with the other conditional atomic ops, let's drop the microblaze implementation of atomic_dec_if_positive(), and use the generic implementation. With that, we can also drop the local asm/atomic.h and asm/cmpxchg.h headers, as asm-generic/atomic.h is mandatory-y, and we can pull in asm-generic/cmpxchg.h via generic-y. This matches what nios2 and nds32 do today. There should be no functional change as a result of this patch. Signed-off-by:
-
Mark Rutland authored
As h8300's implementation of the atomics isn't using any arch-specific functionality, and its implementation of cmpxchg only uses assembly to non-atomically swap two elements in memory, we may as well use the asm-generic atomic.h and cmpxchg.h, and avoid the duplicate code. Signed-off-by:
-
Mark Rutland authored
As xchg*() and cmpxchg*() may be instrumented by atomic-instrumented.h, it's necessary to include <linux/atomic.h> to use these, rather than <asm/cmpxchg.h>, which is effectively an arch-internal header. In a couple of places we include <asm/cmpxchg.h>, but get away with this as <linux/atomic.h> gets pulled in inidrectly by another include. Before we convert more architectures to use atomic-instrumented.h, let's fix these up to use <linux/atomic.h> so that we don't make things more fragile. Signed-off-by:
-
Mark Rutland authored
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:
-
- May 25, 2021
-
-
Pavel Begunkov authored
After pagefaulting in futex_wake_op() both branches do cond_resched() before retry. Deduplicate it as compilers cannot figure it out themself. Signed-off-by:
Pavel Begunkov <asml.silence@gmail.com> Signed-off-by:
-
- May 13, 2021
-
-
André Almeida authored
Improve futex timeout testing by checking all the operations that supports timeout and their available modes. Signed-off-by:
Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20210427135328.11013-3-andrealmeid@collabora.com
-
