Eric Lee / smarc-fsl-linux-kernel

25 Aug, 2022

1 commit

  • 1b7e0482a   locking/atomic: Make test_and_*_bit() ordered on failure ... Browse Code »

    commit 415d832497098030241605c52ea83d4e2cfa7879 upstream.

    These operations are documented as always ordered in
    include/asm-generic/bitops/instrumented-atomic.h, and producer-consumer
    type use cases where one side needs to ensure a flag is left pending
    after some shared data was updated rely on this ordering, even in the
    failure case.

    This is the case with the workqueue code, which currently suffers from a
    reproducible ordering violation on Apple M1 platforms (which are
    notoriously out-of-order) that ends up causing the TTY layer to fail to
    deliver data to userspace properly under the right conditions. This
    change fixes that bug.

    Change the documentation to restrict the "no order on failure" story to
    the _lock() variant (for which it makes sense), and remove the
    early-exit from the generic implementation, which is what causes the
    missing barrier semantics in that case. Without this, the remaining
    atomic op is fully ordered (including on ARM64 LSE, as of recent
    versions of the architecture spec).

    Suggested-by: Linus Torvalds
    Cc: stable@vger.kernel.org
    Fixes: e986a0d6cb36 ("locking/atomics, asm-generic/bitops/atomic.h: Rewrite using atomic_*() APIs")
    Fixes: 61e02392d3c7 ("locking/atomic/bitops: Document and clarify ordering semantics for failed test_and_{}_bit()")
    Signed-off-by: Hector Martin
    Acked-by: Will Deacon
    Reviewed-by: Arnd Bergmann
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Hector Martin
     

12 Apr, 2019

1 commit

13 Feb, 2018

1 commit

  • 61e02392d   locking/atomic/bitops: Document and clarify ordering semantics for failed test_and_{}_bit() ... Browse Code »

    A test_and_{}_bit() operation fails if the value of the bit is such that
    the modification does not take place. For example, if test_and_set_bit()
    returns 1. In these cases, follow the behaviour of cmpxchg and allow the
    operation to be unordered. This also applies to test_and_set_bit_lock()
    if the lock is found to be be taken already.

    Signed-off-by: Will Deacon
    Acked-by: Peter Zijlstra (Intel)
    Cc: Linus Torvalds
    Cc: Paul E. McKenney
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/1518528619-20049-1-git-send-email-will.deacon@arm.com
    Signed-off-by: Ingo Molnar

    Will Deacon
     

10 Aug, 2017

1 commit

  • 706eeb3e9   Documentation/locking/atomic: Add documents for new atomic_t APIs ... Browse Code »

    Since we've vastly expanded the atomic_t interface in recent years the
    existing documentation is woefully out of date and people seem to get
    confused a bit.

    Start a new document to hopefully better explain the current state of
    affairs.

    The old atomic_ops.txt also covers bitmaps and a few more details so
    this is not a full replacement and we'll therefore keep that document
    around until such a time that we've managed to write more text to cover
    its entire.

    Also please, ReST people, go away.

    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Boqun Feng
    Cc: Linus Torvalds
    Cc: Paul McKenney
    Cc: Peter Zijlstra
    Cc: Randy Dunlap
    Cc: Thomas Gleixner
    Cc: Will Deacon
    Signed-off-by: Ingo Molnar

    Peter Zijlstra