On Friday 08/15 at 09:42 -0700, Jakub Kicinski wrote:

On Fri, 15 Aug 2025 11:44:45 +0100 Pavel Begunkov wrote:

quoted

On 8/15/25 01:23, Jakub Kicinski wrote:

quoted

On Thu, 14 Aug 2025 03:16:11 -0700 Breno Leitao wrote:  

quoted

  2.2) netpoll 				// net poll will call the network subsystem to send the packet
  2.3) lock(&fq->lock);			// Try to get the lock while the lock was already held  

The report for reference:

https://lore.kernel.org/all/fb38cfe5153fd67f540e6e8aff814c60b7129480.camel@gmx.de/ (local)> 

quoted

Where does netpoll take fq->lock ?  

the dependencies between the lock to be acquired
[  107.985514]  and HARDIRQ-irq-unsafe lock:
[  107.985531] -> (&fq->lock){+.-.}-{3:3} {
...
[  107.988053]  ... acquired at:
[  107.988054]    check_prev_add+0xfb/0xca0
[  107.988058]    validate_chain+0x48c/0x530
[  107.988061]    __lock_acquire+0x550/0xbc0
[  107.988064]    lock_acquire.part.0+0xa1/0x210
[  107.988068]    _raw_spin_lock_bh+0x38/0x50
[  107.988070]    ieee80211_queue_skb+0xfd/0x350 [mac80211]
[  107.988198]    __ieee80211_xmit_fast+0x202/0x360 [mac80211]
[  107.988314]    ieee80211_xmit_fast+0xfb/0x1f0 [mac80211]
[  107.988424]    __ieee80211_subif_start_xmit+0x14e/0x3d0 [mac80211]
[  107.988530]    ieee80211_subif_start_xmit+0x46/0x230 [mac80211]

Ah, that's WiFi's stack queuing. Dunno whether we expect netpoll to 
work over WiFi. I suspect disabling netconsole over WiFi may be the 
most sensible way out. Johannes, do you expect mac80211 Tx to be IRQ-safe?

It'd be a bit of a shame IMHO to summarily break netconsole over wifi:
it works well enough in practice that I've personally found it helpful
for quick debugging across large numbers of IoT devices (user context
OOPSes outside net/ usually seem to make it out, as do WARNs and other
non-fatal splats).

But if Johannes' answer is "no", maybe there's no way out :/