Re: [PATCH RFC] rcutorture: Fully test lazy RCU

[Joel Fernandes]

> On Feb 27, 2026, at 7:39 PM, Paul E. McKenney <paulmck@xxxxxxxxxx> 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