[ipipe 4.4][PATCH] ipipe: Fix imbalance of level triggered IRQ states

[ipipe 4.4][PATCH] ipipe: Fix imbalance of level triggered IRQ states

[Florian Bezdeka]

There are two states maintained for each IRQ by the kernel:
  - a software flag flipped by irq_state_{clr,set}_masked()
  - the hardware state flipped by the IRQ chip's irq_mask() and
    irq_unmask() members

When ipipe masks a level triggered IRQ both states were updated while
during unmask only the hardware state was updated.

For the 4.4 series this is not a critical thing as the hardware state is
always updated. Newer kernels avoid calling the low level hardware irq
(un)masking infrastructure by reading the software state first. A
imbalanced IRQ state might skip IRQ masking on next IRQ entry resulting
in IRQ storms.

Backporting the fix from 4.19 and 5.4 to keep the IRQ software state
balanced.

Link: https://lore.kernel.org/xenomai/20220210153313.2229625-1-gunter.grau@philips.com/
Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
---
 kernel/irq/chip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 83dee72e6f0e..c33953e39055 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -797,7 +797,7 @@ void __ipipe_ack_level_irq(struct irq_desc *desc)
 
 void __ipipe_end_level_irq(struct irq_desc *desc)
 {
-	desc->irq_data.chip->irq_unmask(&desc->irq_data);
+	unmask_irq(desc);
 }
 
 void __ipipe_ack_fasteoi_irq(struct irq_desc *desc)
-- 
2.35.1

Re: [ipipe 4.4][PATCH] ipipe: Fix imbalance of level triggered IRQ states

[Jan Kiszka]

On 28.11.22 13:10, Florian Bezdeka wrote:
> There are two states maintained for each IRQ by the kernel:
>   - a software flag flipped by irq_state_{clr,set}_masked()
>   - the hardware state flipped by the IRQ chip's irq_mask() and
>     irq_unmask() members
> 
> When ipipe masks a level triggered IRQ both states were updated while
> during unmask only the hardware state was updated.
> 
> For the 4.4 series this is not a critical thing as the hardware state is
> always updated. Newer kernels avoid calling the low level hardware irq
> (un)masking infrastructure by reading the software state first. A
> imbalanced IRQ state might skip IRQ masking on next IRQ entry resulting
> in IRQ storms.
> 
> Backporting the fix from 4.19 and 5.4 to keep the IRQ software state
> balanced.
> 
> Link: https://lore.kernel.org/xenomai/20220210153313.2229625-1-gunter.grau@philips.com/
> Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
> ---
>  kernel/irq/chip.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index 83dee72e6f0e..c33953e39055 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -797,7 +797,7 @@ void __ipipe_ack_level_irq(struct irq_desc *desc)
>  
>  void __ipipe_end_level_irq(struct irq_desc *desc)
>  {
> -	desc->irq_data.chip->irq_unmask(&desc->irq_data);
> +	unmask_irq(desc);

On 4.19 and 5.4, we only added irq_state_clr_masked(desc). Why taking
the full path here which includes hard-irq disable/enable?

Jan

>  }
>  
>  void __ipipe_ack_fasteoi_irq(struct irq_desc *desc)

-- 
Siemens AG, Technology
Competence Center Embedded Linux