Re: [PATCH net v2 1/2] netpoll: use a raw lock for the deferred transmit queue

[Karl Mehltretter]

On Fri, Oct 09, 2026 at 05:52:25PM +0100, Sebastian Andrzej Siewior wrote:
> 
> I would suggest to untangle that local-irq-disable assumption. Then we
> end up with the ::write_atomic callback on PREEMPT_RT which will raise
> warnings. But those will appear only on panic() and as the last console
> due to CON_NBCON_ATOMIC_UNSAFE so everything will go according to the
> plan.
> On !RT the whole __netpoll_send_skb() will be with disabled interrupts
> due to the console lock. On RT it won't and I don't know if anything
> down the call chain assumes that.
> 
> To illustrate my idea a bit
> 

I've got a candidate based on your sketch. It keeps interrupts enabled
for the RT printer thread and the deferred worker. IRQ-disabled direct
sends keep their existing path.

I have one question about retries. I've kept netpoll's retry budget of
about one tick, with BH disabled until deferring to the worker. The
IRQ-enabled RT sender cannot poll, and with the BH lock enabled the wait
holds off local completion work.

Would you instead defer immediately, or enable BH between attempts?

So far, the RT locking tests look good, including on hardware. The
generic change also removes the sleeping-lock reports with macb and ENA
on Ethernet.

Panic handling and record ordering remain open. The non-RT console and
IRQ-disabled atomic paths still need to be addressed.

Thanks,
Karl