[PATCH net 2/3] net: ethernet: ti: icssg_common: set irq_disabled after disabling TX IRQ

[Siddharth Vadapalli]

On Mon, 2026-02-23 at 18:48 -0800, Jakub Kicinski wrote:
> On Fri, 20 Feb 2026 09:41:58 +0530 Siddharth Vadapalli wrote:
> > The 'irq_disabled' variable indicates the current state of the TX IRQ and
> > is used by the TX 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 TX NAPI
> > handler sees 'irq_disabled' set and invokes enable_irq() before the TX IRQ
> > is actually disabled by disable_irq_nosync(). This results in the following
> > warning:
> > 	Unbalanced enable for IRQ ...
> 
> AFAICT the flow on the Tx bug is not buggy, owner ship of the IRQ
> vector passes handler -> NAPI -> timer. I don't see how those can
> race.

The issue is seen in practice. Interrupt coalescing (hrtimer) isn't used.
The call sequence leading to the warning is:
	net_rx_action
		__napi_poll
			NAPI TX Handler
It does seem strange that the 'net_rx_action' leads to the NAPI TX Handler.
However, it is exactly this path that causes the warning, and it is due to
this that we could end up in the following situation:

			CPU0						
				CPU1
		----------------
								--------------
1.	TX HARD IRQ Handler entered				NAPI TX
Handler is running
2.	irq_disabled is
set							Sees irq_disabled being set
3.	Starts executing disable_irq_nosync()		Invokes
enable_irq() for TX IRQ before its really disabled
									
			[UNBALANCED IRQ WARNING IS DISPLAYED]

Regards,
Siddharth.