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 heldThe 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