summaryrefslogtreecommitdiffstats
path: root/init
diff options
context:
space:
mode:
authorPaul E. McKenney <paulmck@linux.vnet.ibm.com>2011-08-24 16:52:09 -0700
committerPaul E. McKenney <paulmck@linux.vnet.ibm.com>2011-09-28 21:38:49 -0700
commitafe24b122eb6edb5f1cb942570ac8d766105c7fc (patch)
treec1f9e2fcbcf2d374f36ee3bfc45babf576cb6246 /init
parente90c53d3e238dd0b7b02964370e8fece1778df96 (diff)
downloadlinux-stable-afe24b122eb6edb5f1cb942570ac8d766105c7fc.tar.gz
linux-stable-afe24b122eb6edb5f1cb942570ac8d766105c7fc.tar.bz2
linux-stable-afe24b122eb6edb5f1cb942570ac8d766105c7fc.zip
rcu: Move propagation of ->completed from rcu_start_gp() to rcu_report_qs_rsp()
It is possible for the CPU that noted the end of the prior grace period to not need a new one, and therefore to decide to propagate ->completed throughout the rcu_node tree without starting another grace period. However, in so doing, it releases the root rcu_node structure's lock, which can allow some other CPU to start another grace period. The first CPU will be propagating ->completed in parallel with the second CPU initializing the rcu_node tree for the new grace period. In theory this is harmless, but in practice we need to keep things simple. This commit therefore moves the propagation of ->completed to rcu_report_qs_rsp(), and refrains from marking the old grace period as having been completed until it has finished doing this. This prevents anyone from starting a new grace period concurrently with marking the old grace period as having been completed. Of course, the optimization where a CPU needing a new grace period doesn't bother marking the old one completed is still in effect: In that case, the marking happens implicitly as part of initializing the new grace period. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Diffstat (limited to 'init')
0 files changed, 0 insertions, 0 deletions