Thread (45 messages) 45 messages, 9 authors, 2025-10-01

Re: netconsole: HARDIRQ-safe -> HARDIRQ-unsafe lock order warning

From: Johannes Berg <johannes@sipsolutions.net>
Date: 2025-08-26 14:10:23
Also in: lkml

On Fri, 2025-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?
I see there's a long thread beyond this, but I just got back from
vacation and haven't read all of it.

As for this question itself, I'd say no. In some cases it probably could
be made safe for mac80211 _itself_ (by adjust that lock and maybe
another one or two), but that wouldn't extend to the drivers, so it'd be
up to the individual drivers. In most cases mac80211 calls wake_tx_queue
(either driver or its own implementation) and that will pull frame(s),
but either way it's going to go all the way into the driver, with
unknown results.

I guess we could do that async since we queue there anyway, but in this
case (of wanting to get things out of a dying system) that'd probably be
counter-productive...

Maybe if it's an individual driver opt-in, but I don't really see it
working for most drivers.

johannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help