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. Thanks. -- Frederic Weisbecker SUSE Labs
