Files
android_kernel_xiaomi_sm8450/include/linux
Paul Burton c3be6577d8 SUNRPC: Use atomic(64)_t for seq_send(64)
The seq_send & seq_send64 fields in struct krb5_ctx are used as
atomically incrementing counters. This is implemented using cmpxchg() &
cmpxchg64() to implement what amount to custom versions of
atomic_fetch_inc() & atomic64_fetch_inc().

Besides the duplication, using cmpxchg64() has another major drawback in
that some 32 bit architectures don't provide it. As such commit
571ed1fd23 ("SUNRPC: Replace krb5_seq_lock with a lockless scheme")
resulted in build failures for some architectures.

Change seq_send to be an atomic_t and seq_send64 to be an atomic64_t,
then use atomic(64)_* functions to manipulate the values. The atomic64_t
type & associated functions are provided even on architectures which
lack real 64 bit atomic memory access via CONFIG_GENERIC_ATOMIC64 which
uses spinlocks to serialize access. This fixes the build failures for
architectures lacking cmpxchg64().

A potential alternative that was raised would be to provide cmpxchg64()
on the 32 bit architectures that currently lack it, using spinlocks.
However this would provide a version of cmpxchg64() with semantics a
little different to the implementations on architectures with real 64
bit atomics - the spinlock-based implementation would only work if all
access to the memory used with cmpxchg64() is *always* performed using
cmpxchg64(). That is not currently a requirement for users of
cmpxchg64(), and making it one seems questionable. As such avoiding
cmpxchg64() outside of architecture-specific code seems best,
particularly in cases where atomic64_t seems like a better fit anyway.

The CONFIG_GENERIC_ATOMIC64 implementation of atomic64_* functions will
use spinlocks & so faces the same issue, but with the key difference
that the memory backing an atomic64_t ought to always be accessed via
the atomic64_* functions anyway making the issue moot.

Signed-off-by: Paul Burton <paul.burton@mips.com>
Fixes: 571ed1fd23 ("SUNRPC: Replace krb5_seq_lock with a lockless scheme")
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: Anna Schumaker <anna.schumaker@netapp.com>
Cc: J. Bruce Fields <bfields@fieldses.org>
Cc: Jeff Layton <jlayton@kernel.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: linux-nfs@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2018-11-01 13:55:24 -04:00
..
2018-07-15 13:55:44 +02:00
2018-08-09 14:05:30 -07:00
2018-05-26 09:16:44 +02:00
2018-06-15 18:10:01 -03:00
2018-07-24 14:43:26 -06:00
2018-05-09 17:25:13 +02:00
2018-06-15 18:10:01 -03:00
2018-06-19 10:06:29 -07:00
2018-06-19 10:06:29 -07:00
2018-03-26 15:09:38 +02:00
2018-08-22 10:52:48 -07:00
2018-07-22 14:13:43 +02:00
2018-06-01 07:38:16 -06:00
2018-07-24 19:11:26 +02:00
2018-07-12 10:04:29 -04:00
2018-08-30 17:08:35 +02:00
2018-07-27 09:57:23 +10:00
2018-06-28 20:32:51 +09:00
2018-09-04 21:31:43 +02:00
2018-06-07 17:34:37 -07:00
2018-03-26 08:53:43 -06:00
2018-08-08 11:06:20 +02:00
2018-06-22 13:43:27 +09:00
2018-05-09 12:21:46 -05:00
2018-04-11 10:28:38 -07:00
2018-06-21 12:33:21 +02:00
2018-07-12 21:35:28 +02:00
2018-04-12 09:41:19 -07:00
2018-06-05 08:50:16 -04:00
2018-06-07 17:34:35 -07:00
2018-04-11 10:28:32 -07:00
2018-06-07 17:34:39 -07:00
2018-03-26 13:14:43 -04:00
2018-03-26 13:14:43 -04:00
2018-08-22 10:52:45 -07:00
2018-07-10 17:22:35 +02:00
2018-06-07 17:34:36 -07:00
2018-04-11 10:28:39 -07:00
2018-07-19 11:34:23 +01:00
2018-06-07 17:34:35 -07:00
2018-07-25 13:41:22 -07:00
2018-07-21 10:43:12 -05:00
2018-08-22 10:52:46 -07:00
2018-05-31 00:13:56 +08:00
2018-07-20 01:11:45 +02:00
2018-08-02 17:33:06 -04:00
2018-05-11 17:28:45 -07:00
2018-05-11 17:28:45 -07:00
2018-08-02 17:16:05 +02:00
2018-06-29 08:48:06 -06:00
2018-06-07 17:34:35 -07:00
2018-07-07 17:25:23 +02:00
2018-07-03 09:20:44 +02:00
2018-05-03 15:55:23 -07:00
2018-08-16 12:14:42 -07:00
2018-06-20 11:35:56 +02:00
2018-05-14 09:51:34 -04:00