srcu: Eliminate possibility of destructive counter overflow
authorPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Wed, 12 Apr 2017 22:16:50 +0000 (15:16 -0700)
committerPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Thu, 8 Jun 2017 15:25:23 +0000 (08:25 -0700)
commit881ec9d209d5371c21db89ca1bb19afd3fcadab3
tree04f275f3a297386ecc5a148f97dc4235d162c742
parent17ed2b6c3ad9f80174c32cc19d86a15396abc196
srcu: Eliminate possibility of destructive counter overflow

Earlier versions of Tree SRCU were subject to a counter overflow bug that
could theoretically result in too-short grace periods.  This commit
eliminates this problem by adding an update-side memory barrier.
The short explanation is that if the updater sums the unlock counts
too late to see a given __srcu_read_unlock() increment, that CPU's
next __srcu_read_lock() must see the new value of ->srcu_idx, thus
incrementing the other bank of counters.  This eliminates the possibility
of destructive counter overflow as long as the srcu_read_lock() nesting
level does not exceed floor(ULONG_MAX/NR_CPUS/2), which should be an
eminently reasonable nesting limit, especially on 64-bit systems.

Reported-by: Lance Roy <ldr709@gmail.com>
Suggested-by: Lance Roy <ldr709@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
kernel/rcu/srcutree.c