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