Re: [PATCH v3 4/8] irqchip/al-fic: switch to shared parent interrupt

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] irqchip: al-fic: uninitialized mask_cache causes false IRQ_HANDLED in shared handler
--

commit cfdc04eba40afdf67fb8743fd9c337f5dc214952
Author: Eliav Farber <farbere@amazon.com>
Subject: irqchip/al-fic: switch to shared parent interrupt

This commit modifies the AL-FIC driver to request its parent interrupt as a
shared interrupt instead of using a chained handler. This change allows
multiple FIC controllers to share a single output line toward the parent GIC.

[Severity: High]
In drivers/irqchip/irq-al-fic.c, at line 169 within al_fic_register(), the
parent IRQ is now requested with IRQF_SHARED. Because the generic chip is
allocated with IRQ_GC_INIT_MASK_CACHE, gc->mask_cache is initialized to 0
and hardware sync is deferred until the first child IRQ is mapped.

Does requesting the shared IRQ at this stage expose the handler to early
execution if another device sharing the line raises an interrupt before any
child IRQs are mapped?

If this occurs, when al_fic_irq_handler() is called around line 105,
the bitwise NOT of gc->mask_cache evaluates to 0xFFFFFFFF. Any latched but
masked events in the AL_FIC_CAUSE register would then bypass the software
mask, resulting in a non-zero pending value.

Could this cause the handler to loop over unmapped bits and falsely return
IRQ_HANDLED? Falsely returning IRQ_HANDLED defeats the kernel's spurious
interrupt detector, which might lead to system hard lockups if the shared
line experiences a spurious storm or becomes stuck.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005112458.22291-1-farbere@amazon.com?part=4