The preemptible RCU flavour doesn't rely at all on
struct rcu_data::cpu_no_qs::b::exp and use its own
struct rcu_data::exp_deferred_qs field to record the need for an
expedited quiescent state.
In fact rdp.cpu_no_qs.b.exp should never be set in preemptible RCU.
Make that fact clear and disambiguate the expectations on the
preemptible RCU's rcu_qs() implementation. In this flavour, common
quiescent states aren't expected to deal with expedited grace periods
because those have their own way to report expedited quiescent states:
rcu_read_unlock_special, context switches, etc...
Signed-off-by: Frederic Weisbecker <frederic@xxxxxxxxxx>
---
kernel/rcu/tree_plugin.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 1a6fdb03d0a5..4c9aeabec242 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -277,12 +277,16 @@ static void rcu_preempt_ctxt_queue(struct rcu_node *rnp, struct rcu_data *rdp)
* current task, there might be any number of other tasks blocked while
* in an RCU read-side critical section.
*
+ * Unlike non-preemptible-RCU, quiescent state reports for expedited
+ * grace periods are handled seperately via deferred quiescent states
+ * and context switch events.
+ *
* Callers to this function must disable preemption.
*/
static void rcu_qs(void)
{
RCU_LOCKDEP_WARN(preemptible(), "rcu_qs() invoked with preemption enabled!!!\n");
- if (__this_cpu_read(rcu_data.cpu_no_qs.s)) {
+ if (__this_cpu_read(rcu_data.cpu_no_qs.b.norm)) {
trace_rcu_grace_period(TPS("rcu_preempt"),
__this_cpu_read(rcu_data.gp_seq),
TPS("cpuqs"));
--
2.25.1
