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/[email protected]/
Cc: [email protected] # v5.9+
Signed-off-by: Rasmus Villemoes <[email protected]>
---
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,
--
2.31.1
On Fri, Jul 2, 2021 at 3:37 PM Rasmus Villemoes
<[email protected]> 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/[email protected]/
>
> Cc: [email protected] # v5.9+
> Signed-off-by: Rasmus Villemoes <[email protected]>
> ---
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/[email protected]/
>
> Cc: [email protected] # v5.9+
> Signed-off-by: Rasmus Villemoes <[email protected]>
> ---
> Thomas, please correct me if I misinterpreted your explanation.
Nothing to correct here.
Reviewed-by: Thomas Gleixner <[email protected]>