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

On Wed 2026-06-17 13:19:58, Peter Zijlstra wrote:

On Wed, Jun 17, 2026 at 12:37:30PM +0200, Petr Mladek wrote:

quoted

On Tue 2026-06-16 14:17:19, Jakub Kicinski wrote:

quoted

On Tue, 16 Jun 2026 19:02:57 +0200 Peter Zijlstra wrote:

quoted

quoted

So this is not an issue since commit 7eab73b18630e ("netconsole: convert
to NBCON console infrastructure"). Because from here now on writes are
deferred to the nbcon thread. So this purely about -stable in this case.  

Hmm, I thought netconsole had some reserved skbs and could to writes
'atomic' like? That said, it was 2.6 era the last time I looked at
netconsole.

Yes, that part is fine. The problem is that netconsole tries
to reap Tx completions if the Tx queue is full. We can't call
skb destructor in irq context so we put the completed skbs on
a queue and try to arm softirq to get to them later.
Arming softirq causes a ksoftirq wake up.

We already skip the completion polling if we detect getting called
from the same networking driver. It's best effort, anyway.
Networking-side fix would be to toss another OR condition into
the skip. But we don't have one that'd work cleanly :S

Alternative solution might be to offload the ksoftirq wake up
to an irq_work. It might make this part safe for the
console->write_atomic() call.

Well, my understanding is that there are more problems.
AFAIK, some drivers do not use an IRQ safe locking, see
https://lore.kernel.org/all/oth5t27z6acp7qxut7u45ekyil7djirg2ny3bnsvnzeqasavxb@nhwdxahvcosh/ (local)

But anything using locking is not ->write_atomic() and should be driven
from a kthread, no?

Right. I am not sure where my head was this morning.

Best Regards,
Petr