On Tue, Jun 10, 2025 at 01:26:46AM +0200, Frederic Weisbecker wrote: > Le Mon, Jun 09, 2025 at 12:49:06PM -0700, Boqun Feng a écrit : > > Hi Joel, > > > > On Mon, Jun 09, 2025 at 02:01:24PM -0400, Joel Fernandes wrote: > > > During rcu_read_unlock_special(), if this happens during irq_exit(), we > > > can lockup if an IPI is issued. This is because the IPI itself triggers > > > the irq_exit() path causing a recursive lock up. > > > > > > This is precisely what Xiongfeng found when invoking a BPF program on > > > the trace_tick_stop() tracepoint As shown in the trace below. Fix by > > > using context-tracking to tell us if we're still in an IRQ. > > > context-tracking keeps track of the IRQ until after the tracepoint, so > > > it cures the issues. > > > > > > > This does fix the issue, but do we know when the CPU will eventually > > report a QS after this fix? I believe we still want to report a QS as > > early as possible in this case? > > If !ct_in_irq(), we issue a self-IPI, then preempt_schedule_irq() will > call into schedule() and report a QS (if preempt/bh is not disabled, otherwise > this is delayed to preempt_enable() or local_bh_enable() issuing > preempt_schedule()) > > If ct_in_irq(), we are already in an IRQ, then it's the same as above > eventually. >
I see, I was missing this, thanks for pointing out ;-) Regards, Boqun > Thanks. > > -- > Frederic Weisbecker > SUSE Labs >
