Messages in this thread | | | From | Valentin Schneider <> | Subject | Re: [PATCH v2 2/6] genirq: Allow an interrupt to be marked as 'raw' | Date | Thu, 03 Dec 2020 15:52:44 +0000 |
| |
On 03/12/20 13:03, Peter Zijlstra wrote: > On Thu, Nov 26, 2020 at 06:18:33PM +0000, Valentin Schneider wrote: >> If I got the RCU bits right from what Thomas mentioned in >> >> https://lore.kernel.org/r/87ft5q18qs.fsf@nanos.tec.linutronix.de >> https://lore.kernel.org/r/87lfewnmdz.fsf@nanos.tec.linutronix.de >> >> then we're still missing something to notify RCU in the case the IRQ hits >> the idle task. All I see on our entry path is >> >> trace_hardirqs_off(); >> ... >> irq_handler() >> handle_domain_irq(); >> ... >> trace_hardirqs_on(); >> >> so we do currently rely on handle_domain_irq()'s irq_enter() + irq_exit() >> for that. rcu_irq_enter() says CONFIG_RCU_EQS_DEBUG=y can detect missing >> bits, but I don't get any warnings with your series on my Juno. > > The scheduler IPI really doesn't need RCU either ;-)
Because it doesn't enter any new read-side section, right? But as with any other interrupt, we could then go through:
preempt_schedule_irq() ~> pick_next_task_fair() -> newidle_balance()
which does enter a read-side section, so RCU would need to be watching. Looking at kernel/entry/common.c:irqentry_exit_cond_resched(), it seems we do check for this via rcu_irq_exit_check_preempt().
I however cannot grok why irqentry_exit() *doesn't* call into preempt_schedule_irq() if RCU wasn't watching on IRQ entry, so I'm starting to question everything (again).
| |