On Sat, Feb 28, 2026 at 10:09:11PM -0500, Joel Fernandes wrote:
> > 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?
He was running an old rcutorture without call_rcu_hurry(), which did
splat. This got me thinking about how to test better. This patch,
right or wrong, is what came to mind.
> > 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().
True, but this patch removes the _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.
OK, done with IS_ENABLED().
> > 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.
That will require an accessor function, but easy enough to do. I will
update.
> > 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.
The splat is on an old kernel where rcutorture does not yet have
call_rcu_hurry(). So this patch isn't fixing a bug, but rather allegedly
improving lazy RCU rcutorture testing.
Thanx, Paul
