This reverts commit 3d5bfbd9716318b1ca5c38488aa69f64d38a9aa5.
When booting with threadirqs, it causes a splat
WARNING: CPU: 0 PID: 29 at kernel/irq/handle.c:159 __handle_irq_event_percpu+0x1ec/0x27c irq 66 handler irq_default_primary_handler+0x0/0x1c enabled interrupts
That splat later went away with commit 81e2073c175b ("genirq: Disable interrupts for force threaded handlers"), which got backported to -stable. However, when running an -rt kernel, the splat still exists. Moreover, quoting Thomas Gleixner [1]
But 3d5bfbd97163 ("gpio: mpc8xxx: change the gpio interrupt flags.") has nothing to do with that:
"Delete the interrupt IRQF_NO_THREAD flags in order to gpio interrupts can be threaded to allow high-priority processes to preempt."
This changelog is blatantly wrong. In mainline forced irq threads have always been invoked with softirqs disabled, which obviously makes them non-preemptible.
So the patch didn't even do what its commit log said.
[1] https://lore.kernel.org/lkml/871r8zey88.ffs@nanos.tec.linutronix.de/
Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: Rasmus Villemoes linux@rasmusvillemoes.dk --- Thomas, please correct me if I misinterpreted your explanation.
drivers/gpio/gpio-mpc8xxx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c index 4b9157a69fca..50b321a1ab1b 100644 --- a/drivers/gpio/gpio-mpc8xxx.c +++ b/drivers/gpio/gpio-mpc8xxx.c @@ -405,7 +405,7 @@ static int mpc8xxx_probe(struct platform_device *pdev)
ret = devm_request_irq(&pdev->dev, mpc8xxx_gc->irqn, mpc8xxx_gpio_irq_cascade, - IRQF_SHARED, "gpio-cascade", + IRQF_NO_THREAD | IRQF_SHARED, "gpio-cascade", mpc8xxx_gc); if (ret) { dev_err(&pdev->dev,
On Fri, Jul 2, 2021 at 3:37 PM Rasmus Villemoes linux@rasmusvillemoes.dk wrote:
This reverts commit 3d5bfbd9716318b1ca5c38488aa69f64d38a9aa5.
When booting with threadirqs, it causes a splat
WARNING: CPU: 0 PID: 29 at kernel/irq/handle.c:159 __handle_irq_event_percpu+0x1ec/0x27c irq 66 handler irq_default_primary_handler+0x0/0x1c enabled interrupts
That splat later went away with commit 81e2073c175b ("genirq: Disable interrupts for force threaded handlers"), which got backported to -stable. However, when running an -rt kernel, the splat still exists. Moreover, quoting Thomas Gleixner [1]
But 3d5bfbd97163 ("gpio: mpc8xxx: change the gpio interrupt flags.") has nothing to do with that:
"Delete the interrupt IRQF_NO_THREAD flags in order to gpio interrupts can be threaded to allow high-priority processes to preempt."
This changelog is blatantly wrong. In mainline forced irq threads have always been invoked with softirqs disabled, which obviously makes them non-preemptible.
So the patch didn't even do what its commit log said.
[1] https://lore.kernel.org/lkml/871r8zey88.ffs@nanos.tec.linutronix.de/
Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: Rasmus Villemoes linux@rasmusvillemoes.dk
Applied for fixes, thanks!
Bartosz
On Fri, Jul 02 2021 at 15:37, Rasmus Villemoes wrote:
This reverts commit 3d5bfbd9716318b1ca5c38488aa69f64d38a9aa5.
When booting with threadirqs, it causes a splat
WARNING: CPU: 0 PID: 29 at kernel/irq/handle.c:159 __handle_irq_event_percpu+0x1ec/0x27c irq 66 handler irq_default_primary_handler+0x0/0x1c enabled interrupts
That splat later went away with commit 81e2073c175b ("genirq: Disable interrupts for force threaded handlers"), which got backported to -stable. However, when running an -rt kernel, the splat still exists. Moreover, quoting Thomas Gleixner [1]
But 3d5bfbd97163 ("gpio: mpc8xxx: change the gpio interrupt flags.") has nothing to do with that:
"Delete the interrupt IRQF_NO_THREAD flags in order to gpio interrupts can be threaded to allow high-priority processes to preempt."
This changelog is blatantly wrong. In mainline forced irq threads have always been invoked with softirqs disabled, which obviously makes them non-preemptible.
So the patch didn't even do what its commit log said.
[1] https://lore.kernel.org/lkml/871r8zey88.ffs@nanos.tec.linutronix.de/
Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: Rasmus Villemoes linux@rasmusvillemoes.dk
Thomas, please correct me if I misinterpreted your explanation.
Nothing to correct here.
Reviewed-by: Thomas Gleixner tglx@linutronix.de
linux-stable-mirror@lists.linaro.org