Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <acb77f59a5e6488b54197cd89a3c1f4f8f5ec585.camel@sipsolutions.net>
Subject: Re: netconsole fail, iwlwifi, WARNING: at net/mac80211/tx.c:3638
 ieee80211_tx_dequeue
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Chris Murphy <lists@colorremedies.com>
Cc:     linux-wireless <linux-wireless@vger.kernel.org>
Date:   Wed, 23 Mar 2022 14:23:58 +0100
In-Reply-To: <CAJCQCtQa+zpHHMsaAq2MYsdZ1bDTfZNyPBgi2Y1hs9OgWxihaw@mail.gmail.com>
References: <CAJCQCtQsvWMzVPDdLeGOwMWtZgfS3qLvFkPOtUbuFT640emW4w@mail.gmail.com>
         <CAJCQCtQa+zpHHMsaAq2MYsdZ1bDTfZNyPBgi2Y1hs9OgWxihaw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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