Files
kernel_google_wahoo/include/linux
Will Deacon 654672d4ba locking/atomics: Add _{acquire|release|relaxed}() variants of some atomic operations
Whilst porting the generic qrwlock code over to arm64, it became
apparent that any portable locking code needs finer-grained control of
the memory-ordering guarantees provided by our atomic routines.

In particular: xchg, cmpxchg, {add,sub}_return are often used in
situations where full barrier semantics (currently the only option
available) are not required. For example, when a reader increments a
reader count to obtain a lock, checking the old value to see if a writer
was present, only acquire semantics are strictly needed.

This patch introduces three new ordering semantics for these operations:

  - *_relaxed: No ordering guarantees. This is similar to what we have
               already for the non-return atomics (e.g. atomic_add).

  - *_acquire: ACQUIRE semantics, similar to smp_load_acquire.

  - *_release: RELEASE semantics, similar to smp_store_release.

In memory-ordering speak, this means that the acquire/release semantics
are RCpc as opposed to RCsc. Consequently a RELEASE followed by an
ACQUIRE does not imply a full barrier, as already documented in
memory-barriers.txt.

Currently, all the new macros are conditionally mapped to the full-mb
variants, however if the *_relaxed version is provided by the
architecture, then the acquire/release variants are constructed by
supplementing the relaxed routine with an explicit barrier.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Waiman.Long@hp.com
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1438880084-18856-2-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-08-12 11:58:59 +02:00
..
2015-07-17 16:39:53 -07:00
2015-06-25 11:49:31 +03:00
2015-05-31 13:40:53 +02:00
2015-05-13 12:04:55 -05:00
2015-07-07 22:48:25 +02:00
2015-03-25 20:28:11 -04:00
2015-06-02 08:33:34 -06:00
2015-04-17 09:03:53 -04:00
2015-06-01 14:35:56 -06:00
2015-02-12 18:54:15 -08:00
2014-12-19 22:55:06 +01:00
2015-05-05 13:35:39 -06:00
2015-01-21 19:21:30 +01:00
2014-12-31 13:06:50 -05:00
2015-06-24 17:49:45 -07:00
2015-05-12 10:46:53 +02:00
2015-06-01 14:33:35 +02:00
2015-06-19 15:18:28 +02:00
2015-03-16 21:45:54 +11:00
2015-05-05 13:40:42 -06:00
2015-01-27 11:09:13 +01:00
2015-06-25 12:06:45 +02:00
2015-01-15 10:34:54 +01:00
2015-04-29 17:17:17 -05:00
2015-01-04 23:11:43 -05:00
2015-04-14 16:49:05 -07:00
2015-03-25 11:44:52 +01:00
2015-06-24 17:49:41 -07:00
2015-06-25 04:20:04 -04:00
2015-05-09 22:15:31 -04:00
2015-07-04 14:04:44 -04:00
2015-06-05 10:58:34 -06:00
2015-03-11 17:56:28 -04:00
2015-04-12 21:03:31 +02:00
2015-01-25 23:17:28 -05:00
2015-06-19 01:18:14 +02:00
2015-06-12 11:36:30 +02:00
2015-06-10 19:14:04 +08:00
2015-05-27 12:58:04 -07:00
2015-05-26 15:23:23 +02:00
2015-06-25 01:13:43 +02:00
2015-06-23 18:01:07 -04:00
2015-06-29 10:49:51 -07:00
2015-02-13 21:21:41 -08:00
2015-04-11 15:53:35 -04:00
2015-06-25 17:00:40 -07:00
2015-05-19 09:19:59 -06:00
2015-06-25 17:00:39 -07:00
2015-05-18 14:08:58 -07:00
2015-05-29 17:21:45 -05:00
2015-04-11 22:29:44 -04:00
2015-06-12 17:26:57 -07:00
2015-03-24 09:48:14 -07:00
2015-06-25 17:00:37 -07:00
2015-04-15 16:35:20 -07:00