diff options
author | Frederic Weisbecker <[email protected]> | 2010-12-10 22:11:11 +0100 |
---|---|---|
committer | Paul E. McKenney <[email protected]> | 2010-12-17 12:34:19 -0800 |
commit | 5ff8e6f0535fe730e921ca347bc38dcb9e01791a (patch) | |
tree | 84940db74c49e9312cd6b0295fa03a04603673a3 /scripts/basic/docproc.c | |
parent | 20377f32dcb77941d450728da18cce5b1a7faec5 (diff) |
rcu: Keep gpnum and completed fields synchronized
When a CPU that was in an extended quiescent state wakes
up and catches up with grace periods that remote CPUs
completed on its behalf, we update the completed field
but not the gpnum that keeps a stale value of a backward
grace period ID.
Later, note_new_gpnum() will interpret the shift between
the local CPU and the node grace period ID as some new grace
period to handle and will then start to hunt quiescent state.
But if every grace periods have already been completed, this
interpretation becomes broken. And we'll be stuck in clusters
of spurious softirqs because rcu_report_qs_rdp() will make
this broken state run into infinite loop.
The solution, as suggested by Lai Jiangshan, is to ensure that
the gpnum and completed fields are well synchronized when we catch
up with completed grace periods on their behalf by other cpus.
This way we won't start noting spurious new grace periods.
Suggested-by: Lai Jiangshan <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Cc: Paul E. McKenney <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Steven Rostedt <[email protected]
Signed-off-by: Paul E. McKenney <[email protected]>
Diffstat (limited to 'scripts/basic/docproc.c')
0 files changed, 0 insertions, 0 deletions