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

On Tue, Jun 16, 2026 at 12:35:29PM +0200, Sebastian Andrzej Siewior wrote:

On 2026-06-11 19:11:14 [-0700], Jakub Kicinski wrote:

quoted

On Wed, 10 Jun 2026 11:36:21 -0700 Vlad Poenaru wrote:

quoted

@@ -194,11 +194,56 @@ void netpoll_poll_dev(struct net_device *dev)
+	local_bh_disable();
+ 	poll_napi(dev);
+	_local_bh_enable();

tglx, Sebastian, are you okay with using _local_bh_enable() to trick
softirq into not waking ksoftirqd? The problematic path is:

  scheduler -> printk -> netconsole -> raise softirq -> scheduler (deadlock)

so the softirq may never get serviced.

In netcons we try to avoid touching the network driver if the Tx path
locks are already held. Ideally we'd do something similar with the
scheduler. Try to do bare minimum if we may be in the scheduler.
Failing that - don't poll the driver if we were called with irqs
already disabled.

Or maybe we only poll from console->write_thread ?

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.

Does the nbcon thread handle defer even for consoles that support atomic
operations?

netconsole is marked with CON_NBCON_ATOMIC_UNSAFE, which means it rarely
performs inline/direct printk and instead pushes to the thread, which
flushes in a safe context.

For drivers that behave correctly, I'd like to be able to drop
CON_NBCON_ATOMIC_UNSAFE, potentially setting it at runtime based on the
underlying driver capabilities. If netconsole is backed by a well-behaving
network driver, we could eventually remove the flag (!?)

Would that approach cause any issues?