[PATCH net 1/3] net: ethernet: ti: am65-cpsw-nuss: set irq_disabled after disabling RX IRQ
Siddharth Vadapalli
s-vadapalli at ti.com
Mon Feb 23 21:10:05 PST 2026
On Mon, 2026-02-23 at 18:48 -0800, Jakub Kicinski wrote:
> On Fri, 20 Feb 2026 09:41:57 +0530 Siddharth Vadapalli wrote:
> > The 'irq_disabled' variable indicates the current state of the RX IRQ and
> > is used by the RX NAPI handler to determine whether the IRQ should be
> > enabled.
> >
> > Currently, 'irq_disabled' is set before actually disabling the IRQ by
> > invoking disable_irq_nosync(). In an SMP environment, this leads to a race
> > condition wherein the processor taking the interrupt sets 'irq_disabled'
> > while another processor executing a previous instance of the RX NAPI
> > handler sees 'irq_disabled' set and invokes enable_irq() before the RX IRQ
> > is actually disabled by disable_irq_nosync(). This results in the following
> > warning:
> > Unbalanced enable for IRQ ...
> >
> > Fix this by disabling the RX IRQ using disable_irq_nosync() before setting
> > 'irq_disabled'.
>
> I'm not sure this is enough. The IRQ enable/disable serves as barriers
> so the ordering is sane. I think the problem is that there are multiple
> paths for Rx which may schedule NAPI, not just the path from the IRQ
> handler. If the state changes have to be atomic you need a lock.
I assume that state changes will be atomic since 'irq_disabled' is set in
the HARD
IRQ handler. Only the processor taking the interrupt will be able to update
the state.
Other processors can read the variable during their execution of the
previous NAPI
RX handlers. Only when 'irq_disabled' is set they will invoke
'enable_irq()'. So the race
condition that you are referring to, is possible during the 'enable_irq()'
path:
In am65_cpsw_nuss_rx_poll() => The RX NAPI Handler
...
if (flow->irq_disabled) {
flow->irq_disabled = false;
...
enable_irq();
CPU1 sees irq_disabled being 'true' and before it updates it to 'false', if
CPU2 also sees irq_disabled
being 'true', both CPU1 and CPU2 will enter the IF-condition and eventually
invoke enable_irq().
Please let me know if this is what you were referring to. I will use atomic
APIs at all places to update
'irq_disabled'.
Regards,
Siddharth.
More information about the linux-arm-kernel
mailing list