Skip to content
  • Paul Burton's avatar
    SUNRPC: Use atomic(64)_t for seq_send(64) · c3be6577
    Paul Burton authored
    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
    571ed1fd
    
     ("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: default avatarPaul Burton <paul.burton@mips.com>
    Fixes: 571ed1fd
    
     ("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: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
    c3be6577