> On Feb 27, 2026, at 7:39 PM, Paul E. McKenney <[email protected]> wrote: > > Currently, rcutorture bypasses lazy RCU by using call_rcu_hurry(). > This works, avoiding the dreaded rtort_pipe_count WARN(), but fails to > fully test lazy RCU. The rtort_pipe_count WARN() splats because lazy RCU > could delay the start of an RCU grace period for a full stutter period, > which defaults to only three seconds.
But call_rcu_hurry() should completely flush, so if we are still splatting with it, does that not mean that there is a real bug the splat uncovered? > This commit therefore reverts the call_rcu_hurry() instances > back to call_rcu(), but, in kernels built with CONFIG_RCU_LAZY=y, > queues a workqueue handler just before the call to stutter_wait() in > rcu_torture_writer(). This workqueue handler invokes rcu_barrier(), > which motivates any lingering lazy callbacks, thus avoiding the splat. But nothing should be lingering with _hurry(). > Questions for review: > > 1. Should we avoid queueing work for RCU implementations not > supporting lazy callbacks? I think so, best to isolate non Lazy cases so the barrier call does not cause side effects. > 2. Should we avoid queueing work in kernels built with > CONFIG_RCU_LAZY=y, but that were not booted with the > rcutree.enable_rcu_lazy kernel boot parameter set? (Note that > this requires some ugliness to access this parameter, and must > also handle Tiny RCU.) Yes I think we should avoid. > 3. Does the rcu_torture_ops structure need a ->call_hurry() field, > and if so, why? If not, why not? > > 4. Your additional questions here! Do we have a reproducer for the splat? If there is a link to the report, I could take a look and investigate. thanks, -- Joel Fernandes
