[RFC] synchronize_irq() does not wait for chained interrupt handlers

[RFC] synchronize_irq() does not wait for chained interrupt handlers

[Ali Tariq]

Hi,

While reviewing drivers/pci/controller/plda/pcie-plda-host.c, I found
that synchronize_irq() does not appear to provide the guarantee I
expected for chained interrupt handlers (registered via
irq_set_chained_handler_and_data()).

Tracing through kernel/irq/manage.c:
- synchronize_irq()'s wait relies on the IRQD_IRQ_INPROGRESS flag
- That flag is set/cleared by handle_irq_event(), part of the normal
  (non-chained) dispatch path
- Chained handlers bypass that path entirely and dispatch goes straight
  to desc->handle_irq
- The fallback, __irq_get_irqchip_state() via .irq_get_irqchip_state(),
  only works if the irq_chip implements that callback

In the PLDA PCIe driver's case, none of its irq_chip structures
implement .irq_get_irqchip_state(), so synchronize_irq() called after
irq_set_chained_handler_and_data(irq, NULL, NULL) returns immediately,
regardless of whether the chained handler is still executing on
another CPU. (I originally submitted a fix using synchronize_irq()
for this driver; withdrawing it once I traced this through [1])

This was originally flagged by an automated review (Sashiko AI) on a
patch I submitted for the StarFive PCIe driver [2]. Tracing through
kernel/irq/manage.c to verify the finding led me to the
IRQD_IRQ_INPROGRESS/chained-handler gap described above. Bjorn Helgaas
then asked whether other drivers using the same pattern would need
similar handling [3], which prompted the wider search below.

I searched the tree for other callers of
irq_set_chained_handler_and_data(irq, NULL, NULL) and found roughly
30 call sites with a similar shape, mostly in driver .remove()/teardown
paths. I haven't individually verified severity for each - it seems to
depend on what runs immediately after teardown in each specific driver
(e.g. whether clocks/power are cut shortly after, as in the PLDA case).

A partial list of files where the same call sequence is present:

arch/arm/common/locomo.c
arch/arm/common/sa1111.c
drivers/gpio/gpio-brcmstb.c
drivers/gpio/gpio-mpc8xxx.c
drivers/gpio/gpio-mt7621.c
drivers/gpio/gpio-mxc.c
drivers/gpio/gpio-rockchip.c
drivers/gpu/drm/imx/dc/dc-ic.c
drivers/gpu/drm/msm/msm_mdss.c
drivers/gpu/ipu-v3/ipu-common.c
drivers/irqchip/irq-imgpdc.c
drivers/irqchip/irq-lan966x-oic.c
drivers/irqchip/irq-ls-scfg-msi.c
drivers/irqchip/irq-ts4800.c
drivers/mfd/fsl-imx25-tsadc.c
drivers/pci/controller/pci-mvebu.c

I'm not sure what the right fix looks like at scale - possibly
implementing .irq_get_irqchip_state() where the hardware supports it,
possibly a driver-local synchronization primitive where it doesn't map
cleanly (which seems to be the case for PLDA, since its status
register is acknowledged partway through handler execution, before
the rest of the dispatch work completes).

Is this a known/expected limitation of synchronize_irq() for chained
handlers, or worth addressing more broadly? Happy to do more digging
or send patches if there's a preferred direction.

Thanks,
Ali

[1] https://lore.kernel.org/linux-pci/20260714174345.1073909-1-alitariq45892@gmail.com/
[2] https://lore.kernel.org/linux-pci/20260713150346.B57F11F000E9@smtp.kernel.org/
[3] https://lore.kernel.org/linux-pci/20260714175852.GA1387886@bhelgaas/