Re: [PATCH] PCI: iproc-msi: Bound events handled per IRQ

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci: iproc-msi: missing dma_rmb() after TAIL register read
--

commit 8736e22d751e9208bad7bb267a7f08a76f8d4f77
Author: Eugen Hristev <ehristev@kernel.org>

    PCI: iproc-msi: Bound events handled per IRQ
    
    Limit each iProc MSI parent IRQ to 16 event-queue entries.
    
    A continuously fed queue could otherwise keep the chained handler running
    and starve other work. The budget still drains pending events and lets the
    next parent interrupt continue processing, improving fairness and bounding
    interrupt-handler latency.

> diff --git a/drivers/pci/controller/pcie-iproc-msi.c b/drivers/pci/controller/pcie-iproc-msi.c
> index 9ba242ab95967..6649807822d27 100644
> --- a/drivers/pci/controller/pcie-iproc-msi.c
> +++ b/drivers/pci/controller/pcie-iproc-msi.c

[ ... ]

> @@ -360,9 +364,11 @@ static void iproc_msi_handler(struct irq_desc *desc)
>  			break;
>  
>  		/* process all outstanding events */
> -		while (nr_events--) {
> +		while (nr_events && event_budget) {
>  			hwirq = decode_msi_hwirq(msi, eq, head);

[Severity: High]
Does this sequence lack a necessary dma_rmb() before reading the event queue
in decode_msi_hwirq()?

Because iproc_msi_read_reg() uses readl_relaxed() to read the TAIL register,
weakly-ordered architectures could speculatively execute the DMA memory read
from msi->eq_cpu (inside decode_msi_hwirq()) before the MMIO read of the TAIL
register completes.

Could this result in reading stale hardware IRQ numbers from the event queue
on subsequent iterations of the polling loop, leading to missed or spurious
interrupts?

>  			generic_handle_domain_irq(msi->inner_domain, hwirq);
> +			nr_events--;
> +			event_budget--;
>  
>  			head++;
>  			head %= EQ_LEN;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-iproc-irq-v1-1-ebaaf027f29e@kernel.org?part=1