Files
linux/include/linux
Linus Torvalds 66be4e66a7 rcu: locking and unlocking need to always be at least barriers
Herbert Xu pointed out that commit bb73c52bad ("rcu: Don't disable
preemption for Tiny and Tree RCU readers") was incorrect in making the
preempt_disable/enable() be conditional on CONFIG_PREEMPT_COUNT.

If CONFIG_PREEMPT_COUNT isn't enabled, the preemption enable/disable is
a no-op, but still is a compiler barrier.

And RCU locking still _needs_ that compiler barrier.

It is simply fundamentally not true that RCU locking would be a complete
no-op: we still need to guarantee (for example) that things that can
trap and cause preemption cannot migrate into the RCU locked region.

The way we do that is by making it a barrier.

See for example commit 386afc9114 ("spinlocks and preemption points
need to be at least compiler barriers") from back in 2013 that had
similar issues with spinlocks that become no-ops on UP: they must still
constrain the compiler from moving other operations into the critical
region.

Now, it is true that a lot of RCU operations already use READ_ONCE() and
WRITE_ONCE() (which in practice likely would never be re-ordered wrt
anything remotely interesting), but it is also true that that is not
globally the case, and that it's not even necessarily always possible
(ie bitfields etc).

Reported-by: Herbert Xu <herbert@gondor.apana.org.au>
Fixes: bb73c52bad ("rcu: Don't disable preemption for Tiny and Tree RCU readers")
Cc: stable@kernel.org
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-06-03 13:26:20 -07:00
..
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-05-14 19:52:50 -07:00
…
…
…
…
…
…
2019-04-09 17:05:46 -07:00
…
…
…
2019-05-07 08:39:02 -06:00
…
…
…
…
…
…
…
…
…
2019-05-09 15:25:13 -04:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-02-28 03:28:53 -05:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-02-28 08:24:23 -07:00
…
…
…
…
…
…
…
…
…
…
…
2019-04-22 09:48:12 -06:00
…
…
2019-02-15 16:54:38 +01:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-03-22 14:36:02 +01:00
…
…
…
2019-05-01 07:47:37 -07:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-04-08 22:56:14 +02:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-03-07 18:32:03 -08:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-02-20 07:22:17 -07:00
2019-02-20 07:22:10 -07:00
…
2019-02-08 15:02:49 -08:00
…
…
…
…
…
…
…
…
…
…
…
2019-03-05 21:07:19 -08:00
2019-05-14 09:47:51 -07:00
…
…
…
…
…
…
…
…
…
2019-05-07 14:31:03 +02:00
…
…
…
…
…
…
2019-03-12 10:04:03 -07:00
…
…
2019-05-14 19:52:51 -07:00
…
…
…
2019-05-14 19:52:48 -07:00
…
…
…
…
…
…
…
…
…
2019-04-02 17:57:35 +02:00
…
…
…
…
…
…
2019-05-08 22:14:36 +02:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-05-16 15:51:55 -07:00
…
…
…
…
…
2019-03-15 15:29:47 -07:00
…
…
…
…
…
…
…
…
2019-02-07 16:38:35 +01:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-02-07 00:13:27 +01:00
…
…
…
…
…
…
…
…
2019-04-06 10:48:35 -06:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2019-05-15 17:35:54 +01:00
2019-04-09 15:14:49 -06:00
…
…
…
…
…
…
…
…
…
…
…
…