• Will Deacon's avatar
    READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses · 9e343b46
    Will Deacon authored
    {READ,WRITE}_ONCE() cannot guarantee atomicity for arbitrary data sizes.
    This can be surprising to callers that might incorrectly be expecting
    atomicity for accesses to aggregate structures, although there are other
    callers where tearing is actually permissable (e.g. if they are using
    something akin to sequence locking to protect the access).
    
    Linus sayeth:
    
      | We could also look at being stricter for the normal READ/WRITE_ONCE(),
      | and require that they are
      |
      | (a) regular integer types
      |
      | (b) fit in an atomic word
      |
      | We actually did (b) for a while, until we noticed that we do it on
      | loff_t's etc and relaxed the rules. But maybe we could have a
      | "non-atomic" version of READ/WRITE_ONCE() that is used for the
      | questionable cases?
    
    The slight snag is that we also have to support 64-bit accesses on 32-bit
    architectures, as these appear to be widespread and tend to work out ok
    if either the architecture supports atomic 64-bit accesses (x86, armv7)
    or if the variable being accesses represents a virtual address and
    therefore only requires 32-bit atomicity in practice.
    
    Take a step in that direction by introducing a variant of
    'compiletime_assert_atomic_type()' and use it to check the pointer
    argument to {READ,WRITE}_ONCE(). Expose __{READ,WRITE}_ONCE() variants
    which are allowed to tear and convert the one broken caller over to the
    new macros.
    Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: default avatarWill Deacon <will@kernel.org>
    9e343b46
time.c 4.15 KB