diff options
author | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2011-08-24 16:52:09 -0700 |
---|---|---|
committer | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2011-09-28 21:38:49 -0700 |
commit | afe24b122eb6edb5f1cb942570ac8d766105c7fc (patch) | |
tree | c1f9e2fcbcf2d374f36ee3bfc45babf576cb6246 /init | |
parent | e90c53d3e238dd0b7b02964370e8fece1778df96 (diff) | |
download | op-kernel-dev-afe24b122eb6edb5f1cb942570ac8d766105c7fc.zip op-kernel-dev-afe24b122eb6edb5f1cb942570ac8d766105c7fc.tar.gz |
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