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@xxxxxxxxxxxxx> > > > > 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
