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
> >
