summaryrefslogtreecommitdiffstats
path: root/man/man5
diff options
context:
space:
mode:
authorRichard Yao <[email protected]>2014-12-04 18:47:51 -0500
committerBrian Behlendorf <[email protected]>2015-01-16 13:55:09 -0800
commita988a35a93671c086c38ce5b71b6badb59a9c2de (patch)
treeeac730ab5d5f8103b17acaddfef30f5b86b239e1 /man/man5
parentc2fa09454ef322a34df58655978e79c1c7fab641 (diff)
Enforce architecture-specific barriers around clear_bit()
The comment above the Linux 3.16 kernel's clear_bit() states: /** * clear_bit - Clears a bit in memory * @nr: Bit to clear * @addr: Address to start counting from * * clear_bit() is atomic and may not be reordered. However, it does * not contain a memory barrier, so if it is used for locking purposes, * you should call smp_mb__before_atomic() and/or smp_mb__after_atomic() * in order to ensure changes are visible on other processors. */ This comment does not make sense in the context of x86 because x86 maps the operations to barrier(), which is a compiler barrier. However, it does make sense to me when I consider architectures that reorder around atomic instructions. In such situations, a processor is allowed to execute the wake_up_bit() before clear_bit() and we have a race. There are a few architectures that suffer from this issue. In such situations, the other processor would wake-up, see the bit is still taken and go to sleep, while the one responsible for waking it up will assume that it did its job and continue. This patch implements a wrapper that maps smp_mb__{before,after}_atomic() to smp_mb__{before,after}_clear_bit() on older kernels and changes our code to leverage it in a manner consistent with the mainline kernel. Signed-off-by: Brian Behlendorf <[email protected]>
Diffstat (limited to 'man/man5')
0 files changed, 0 insertions, 0 deletions