On Wed, 2022-02-16 at 20:44 -0700, Chris Murphy wrote:
> So this is quite a bit more verbose with kernel
> 5.17.0-0.rc4.96.fc36.x86_64+debug.
>
> Is netconsole expected to work from a host with wifi?
Let's say it seems pretty audacious to try? There's a huge stack between
the hardware and the network (MAC service) interface...
We might sometimes even need to do memory allocations to send out a
frame, or touch other hardware (e.g. crypto engines if crypto is not in
wifi HW) etc.
We also didn't really expect to be called from interrupts-disabled
contexts here.
> [ 4970.929723] kernel: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
> [ 4970.929726] kernel: 5.17.0-0.rc4.96.fc36.x86_64+debug #1 Tainted: G W --------- ---
> [ 4970.929728] kernel: -----------------------------------------------------
> [ 4970.929729] kernel: modprobe/8230 [HC0[0]:SC0[2]:HE0:SE0] is trying to acquire:
> [ 4970.929734] kernel: ffff953c499b9070 (&fq->lock){+.-.}-{2:2}, at: ieee80211_xmit_fast+0x412/0xb90 [mac80211]
> [ 4970.929823] kernel:
> and this task is already holding:
> [ 4970.929824] kernel: ffffffffc1504618 (target_list_lock){....}-{2:2}, at: write_msg+0x48/0xf0 [netconsole]
> [ 4970.929834] kernel: which would create a new lock dependency:
> [ 4970.929835] kernel: (target_list_lock){....}-{2:2} -> (&fq->lock){+.-.}-{2:2}
> [ 4970.929840] kernel:
> but this new dependency connects a HARDIRQ-irq-safe lock:
> [ 4970.929841] kernel: (&ec->lock){-.-.}-{2:2}
> [ 4970.929842] kernel:
> ... which became HARDIRQ-irq-safe at:
>
[...]
> [ 4970.930019] kernel:
> to a HARDIRQ-irq-unsafe lock:
> [ 4970.930020] kernel: (&fq->lock){+.-.}-{2:2}
> [ 4970.930022] kernel:
> ... which became HARDIRQ-irq-unsafe at:
> [ 4970.930023] kernel: ...
> [ 4970.930024] kernel: lock_acquire+0xd0/0x2d0
> [ 4970.930027] kernel: _raw_spin_lock_bh+0x38/0x80
> [ 4970.930030] kernel: ieee80211_get_txq_stats+0x49/0x190 [mac80211]
[...]
which is pretty much what it's telling us here, I suppose, just in a bit
more roundabout way.
Unfortunately, I don't think we can really support that - there's so
much code below ... We'd have to make *everything* IRQ safe here?
johannes
