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

[Ray Jui]

Hi Eugen,

Can you please also add a Fixes tag in v2, given that this issue can
cause a RCU stall in corner cases?

Thanks,

Ray

On Wed, Nov 4, 2026 at 12:58 PM 'Eugen Hristev' via
BCM-KERNEL-FEEDBACK-LIST,PDL
<bcm-kernel-feedback-list.pdl@xxxxxxxxxxxx> wrote:
>
> On 10/30/26 19:22, Manivannan Sadhasivam wrote:
> > On 2026-10-16 23:10 +0300, Eugen Hristev wrote:
> >> On 10/16/26 21:21, Bjorn Helgaas wrote:
> >>> On Fri, Oct 16, 2026 at 03:18:53PM +0300, Eugen Hristev wrote:
> >>>> 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.
> >>>>
> >>>> Without this starvation avoidance, one CPU can stall indefinitely
> >>>> in the loop and not serve other interrupts, timers, etc.
> >>>>
> >>>> While testing it with an Ethernet NIC,  when too many MSI interrupts
> >>>> come in, CPU might get starved:
> >>>>
> >>>> Connecting to host 192.168.30.1, port 5201
> >>>> [  5] local 192.168.30.2 port 52586 connected to 192.168.30.1 port 5201
> >>>> [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
> >>>> [  5]   0.00-1.00   sec   240 MBytes  2.01 Gbits/sec    2    334 KBytes
> >>>> [  5]   1.00-2.00   sec  63.2 MBytes   531 Mbits/sec    1   1.41 KBytes
> >>>> [  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> >>>> [  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> >>>> [  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> >>>> [  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> >>>> [  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> >>>> [  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> >>>> [  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> >>>> [  177.568497] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> >>>> [  177.568913] rcu:     0-...!: (1 GPs behind) idle=28ac/1/0x4000000000000002 softirq=28922/28930 fqs=1
> >>>> [  177.569457] rcu:     (detected by 1, t=5256 jiffies, g=21629, q=819 ncpus=4)
> >>>> [  177.569870] Sending NMI from CPU 1 to CPUs 0:
> >>>>
> >>>> With this bounded approach, IRQ handler will complete and continue
> >>>> to serve MSI events on the next handler invocation.
> >>>
> >>> Is there something unique about iproc that makes this an issue, or do
> >>> we need to worry about this in every MSI interrupt handler?
> >>>
> >> This is not specific to iPROC, so in theory it can happen to any other
> >> MSI interrupt handler. If the handler has no way to break the loop, and
> >> the condition that generates the MSI IRQ happens continuously, the same
> >> situation will happen.
> >
> >> Some other drivers e.g. take the IRQ state into a local variable, do the
> >> task, clear it up, and don't care to read it again, like the iPROC is
> >> doing, unless another MSI fires.
> >>
> >
> > You should rework the iproc handler to read head and tail outside of the loop
> > and handle the recorded events inside the loop. This will avoid using any
> > arbitrary max event limit and allow other handlers to also run.
>
> Hi Mani,
>
> Thanks for the feedback, I changed it as you said, sent a v2.
>
> Eugen>
> > - Mani
> >
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature