> > 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. Thanks Zqiang > > Thanks > Sunho Park >
