Messages in this thread | | | From | Valentin Schneider <> | Subject | Re: [PATCH 04/11] ARM: Allow IPIs to be handled as normal interrupts | Date | Thu, 21 May 2020 15:03:49 +0100 |
| |
On 19/05/20 23:24, Russell King - ARM Linux admin wrote: > On Tue, May 19, 2020 at 05:17:48PM +0100, Marc Zyngier wrote: >> In order to deal with IPIs as normal interrupts, let's add >> a new way to register them with the architecture code. >> >> set_smp_ipi_range() takes a range of interrupts, and allows >> the arch code to request them as if the were normal interrupts. >> A standard handler is then called by the core IRQ code to deal >> with the IPI. >> >> This means that we don't need to call irq_enter/irq_exit, and >> that we don't need to deal with set_irq_regs either. So let's >> move the dispatcher into its own function, and leave handle_IPI() >> as a compatibility function. >> >> On the sending side, let's make use of ipi_send_mask, which >> already exists for this purpose. > > You say nothing about the nesting of irq_enter() and irq_exit() > for scheduler_ipi(). > > Given that lockdep introduced the requirement that hard IRQs can't > be nested, are we sure that calling irq_exit() twice is safe? > > Looking at irqtime_account_irq(), it seems that will cause double- > accounting of in-interrupt time, since we will increment > irq_start_time by just over twice the the period spent handling > the IPI. > > I think the rest of irq_exit() should be safe, but still, this > behaviour should be documented at the very least, if not avoided. >
x86 does the same (though IIUC only when tracing reschedule IPI's), and MIPS has the same issue as it also uses generic IRQ IPI's - so although it's not ideal, I think we can live with it.
| |