[PATCH net 1/3] net: ethernet: ti: am65-cpsw-nuss: set irq_disabled after disabling RX IRQ

[Siddharth Vadapalli]

On 25/02/26 05:24, Jakub Kicinski wrote:
> On Tue, 24 Feb 2026 10:40:05 +0530 Siddharth Vadapalli wrote:
>> 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().
> 
> I think the races are just between NAPI and the HARD IRQ context.
> There can only be one NAPI scheduled for a queue, I assume.

Yes. An already executing RX NAPI Handler (scheduled via net_rx_action) 
sees 'irq_disabled' set by the HARD IRQ handler. The RX NAPI Handler then 
executes 'enable_irq()' for the RX IRQ before it is actually disabled by 
the HARD IRQ handler using disable_irq_nosync().

> 
>> Please let me know if this is what you were referring to. I will use atomic
>> APIs at all places to update
>> 'irq_disabled'.
> 
> I recommend a spin lock, unless you can measure as significant
> difference. Locks and atomics have similar cost on many CPUs.
> And juggling local state, IRQ state, and NAPI state atomically
> will get tricky.

Updates to 'irq_disabled' are performed by:

	1. Hard IRQ Handler sets irq_disabled to true.
	   => Since there can be only one IRQ for a given RX Queue,
	    we can be certain that there is no race w.r.t. setting it
	    to true.
	2. NAPI RX Handler sets irq_disabled to false if currently true.
	   => This is the part I am unsure of but if a single instance
	    of the NAPI RX Handler will be scheduled in an SMP
	    environment as well, there won't be a race between
	    multiple processors as the following will cannot happen
	    simultaneously on multiple CPUs running the RX Handler:
		irq_disabled = false;
		enable_irq();

Regards,
Siddharth.