Re: [PATCH net] netpoll: run NAPI poll in softirq context to avoid rq->lock self-deadlock

[Breno Leitao <leitao@debian.org>]

On Wed, Jun 17, 2026 at 01:21:27PM -0700, Jakub Kicinski wrote:
> On Wed, 17 Jun 2026 07:56:50 -0700 Breno Leitao wrote:
> > As far as I can tell, there isn't a network driver today whose transmit
> > path is completely lockless, so, even if we make netpoll lockless.
> > 
> > It's unlikely any NIC will ever achieve this, given that NIC TX
> > fundamentally relies on a shared DMA ring and doorbell register, which
> > inherently cannot be made lockless.
> 
> The lock which protects the queue is maintained by the stack,
> and we trylock it. Maybe I lost the thread but if you're saying
> that writes to netconsole are impossible from arbitrary context,
> that is _not_ true, AFAIU. We can queue a packet and kick off 
> the transfer on well-behaved drivers.
> 
> Main problem is the opportunistic freeing up of the queue space.
> If we could avoid that in atomic context I think we'd be good.

Thanks for the clarification, this is quite valuable.

Let me verify my understanding: if we switched to __raise_softirq_irqoff()
in dev_kfree_skb_irq_reason(), the issue would be resolved since we'd
avoid waking ksoftirqd and therefore wouldn't touch the runqueue lock in this
code path.

However, while that would eliminate the nested lock problem, it could
increase memory pressure by delaying SKB garbage collection, which may
not be acceptable.

Naive question: What if we deferred SKB cleanup only during netpoll operations?

Such as tracking in_netpoll per cpu:

		struct softnet_data {
			....
	+ 		bool                    in_netpoll;
		}

and then choosing between __raise_softirq_irqoff() and raise_softirq_irqoff()?

	@@ -3456,7 +3456,13 @@ void dev_kfree_skb_irq_reason(struct sk_buff *skb, enum skb_drop_reason reason)
		local_irq_save(flags);
		skb->next = __this_cpu_read(softnet_data.completion_queue);
		__this_cpu_write(softnet_data.completion_queue, skb);
	-       raise_softirq_irqoff(NET_TX_SOFTIRQ);
	+       if (__this_cpu_read(softnet_data.in_netpoll))
	+               __raise_softirq_irqoff(NET_TX_SOFTIRQ);
	+       else
	+               raise_softirq_irqoff(NET_TX_SOFTIRQ);
		local_irq_restore(flags);
	}


Is it too hacky!?

Thanks,
--breno