Re: [BUG] srcu: false-positive WARN in cleanup_srcu_struct() after 78a38cbf6f20

[Paul E. McKenney]

On Thu, Aug 27, 2026 at 01:41:54PM +0000, Zqiang wrote:
> > 
> > On 8/27/26 21:40, Zqiang wrote:
> > 
> > > 
> > > Now, I am trying to rephrase your problem in the following way:
> > >  1- the step1 call_srcu() trigger SRCU grace period has been end and queue sdp->work.
> > >  2- the step4 queue srcu callback has been intercepted by step5 srcu_barrier()
> > >  and start a new SRCU grace period.
> > >  3- this new SRCU grace period end, and invoke rcu_seq_end(&sup->srcu_gp_seq), queue a timer.
> > >  4- the sdp->work begin run, and call srcu_segcblist_advance() with current sup->srcu_gp_seq.
> > >  so the step4's srcu callback and step5's barrier calback both to be run.
> > >  all callback finished, but the len not yet update.
> > >  5- the srcu_barrier() return, begin call srcu_clean_up(), and then the srcu_clean_up
> > >  find the a timer is still pending and the cb_len also not be zero, trigger WARN_ON()
> > >  right?
> > > 
> > Exactly. The real callbacks are properly invoked as srcu_barrier() guarantees. The WARN is triggered only by the two transient states: a pending delay_work timer and a stale cblist len. So I think this is a false positive warning.
> > 
> > Sorry if my explanations were too wordy.
> 
> Would you like to send a patch to fix it ?
> 
> remove WARN_ON() or use rcu_segcblist_empty(&sdp->srcu_cblist) to replace rcu_segcblist_n_cbs(&sdp->srcu_cblist) ?
> 
> Let's hear Paul's opinion.

Thank you both for your work on this!  On the choice between
rcu_segcblist_empty() and rcu_segcblist_n_cbs(), if you are just testing
for zero or for non-zero, rcu_segcblist_empty() is better.  It generates
slightly better code, but the main thing is the improved readability.

I will take a closer look once you both are satisfied with it.

							Thanx, Paul

> Thanks
> Zqiang
> 
> > 
> > Thanks
> > Sunho Park
> >