Re: [PATCH 5.4] genirq/affinity: Make affinity setting if activated opt-in

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Aug 10, 2020 at 08:27:40PM +0000, Frank van der Linden wrote:
> On Mon, Aug 10, 2020 at 08:25:03PM +0000, Frank van der Linden wrote:
> > From: Thomas Gleixner <tglx@linutronix.de>
> > 
> > commit f0c7baca180046824e07fc5f1326e83a8fd150c7 upstream.
> > 
> > John reported that on a RK3288 system the perf per CPU interrupts are all
> > affine to CPU0 and provided the analysis:
> > 
> >  "It looks like what happens is that because the interrupts are not per-CPU
> >   in the hardware, armpmu_request_irq() calls irq_force_affinity() while
> >   the interrupt is deactivated and then request_irq() with IRQF_PERCPU |
> >   IRQF_NOBALANCING.
> > 
> >   Now when irq_startup() runs with IRQ_STARTUP_NORMAL, it calls
> >   irq_setup_affinity() which returns early because IRQF_PERCPU and
> >   IRQF_NOBALANCING are set, leaving the interrupt on its original CPU."
> > 
> > This was broken by the recent commit which blocked interrupt affinity
> > setting in hardware before activation of the interrupt. While this works in
> > general, it does not work for this particular case. As contrary to the
> > initial analysis not all interrupt chip drivers implement an activate
> > callback, the safe cure is to make the deferred interrupt affinity setting
> > at activation time opt-in.
> > 
> > Implement the necessary core logic and make the two irqchip implementations
> > for which this is required opt-in. In hindsight this would have been the
> > right thing to do, but ...
> 
> I backported this one since it had a minor conflict, so while the main
> one was Cc-ed to stable@, it didn't get picked up.

I didn't have the chance to get to it in the long list yet :)

I've done so now, and this matches my backport.  I've also backported it
to 4.19.y, and that seems to match this almost identically as well (one
minor difference).

thanks,

greg k-h