Re: [PATCH 04/11] ARM: Allow IPIs to be handled as normal interrupts

[Russell King - ARM Linux admin]

On Thu, May 21, 2020 at 03:03:49PM +0100, Valentin Schneider wrote:
> 
> 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),

Right, so when the system is operating normally, then the accounting is
correct.  When the reschedule path is being explicitly traced, then
the accounting will be doubled for it.

What's being proposed for ARM is to always have this mis-accounting,
where no mis-accounting was present before - and some of us (me) /do/
enable IRQ accounting in our kernels as standard. So, you can take
this as a kernel regression report from a user.

> 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.

Yes, but is there anyone who cares about this for MIPS?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up