From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Kalle Valo <kvalo@codeaurora.org>, Steve French <smfrench@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, linux-wireless@vger.kernel.org
Subject: Re: 5.5-rc1 oops on boot in 802.11 kernel driver
Date: Mon, 09 Dec 2019 15:10:12 +0100 [thread overview]
Message-ID: <87muc1io8r.fsf@toke.dk> (raw)
In-Reply-To: <87h829lpob.fsf@toke.dk>
Toke Høiland-Jørgensen <toke@redhat.com> writes:
> Kalle Valo <kvalo@codeaurora.org> writes:
>
>> Hi Steve,
>>
>> Steve French <smfrench@gmail.com> writes:
>>
>>> Noticed this crash in the Linux kernel Wifi driver on boot a few
>>> minutes ago immediately after updating to latest mainline kernel about
>>> an hour ago. I didn't see it last week and certainly not in 5.4.
>>
>> please CC linux-wireless on all wireless related problems, we don't
>> follow lkml very closely and I found your email just by chance.
>>
>> Full warning below. Steve is using iwlwifi.
>
> Right, we already got a similar report off-list, but with a different
> stack trace. I was going to try to reproduce this on my own machine
> today. However, the fact that this includes the iwl_mvm_tx_reclaim()
> function may be a hint; that code seems to be reusing skbs without
> freeing them?
>
> If I'm reading the code correctly, it seems the reuse leads to the same
> skb being passed to ieee80211_tx_status() multiple times; the driver is
> clearing info->status, but since we added the info->tx_time_est field,
> that would lead to double-accounting of that SKB, which would explain
> the warning?
>
> Can someone familiar with iwlwifi confirm that this is indeed what that
> code is supposed to be doing? If it is, I think it needs the patch
> below; however, if I'm wrong, then clearing the field could lead to the
> opposite problem (that skbs fail to be accounted at all), which would
> lead to the queue being throttled because the limit gets too high and is
> never brought back down...
Right, and now I did boot up my own laptop with the -next kernel, and
tested the patch. It definitely breaks things, so that was not the
issue. However, I don't get the WARN_ON either, so don't have any better
ideas. I guess we'll have to wait for someone who actually knows the
iwlwifi driver to take a look at this :)
-Toke
next prev parent reply other threads:[~2019-12-09 14:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-09 2:49 5.5-rc1 oops on boot in 802.11 kernel driver Steve French
2019-12-09 10:27 ` Kalle Valo
2019-12-09 11:11 ` Toke Høiland-Jørgensen
2019-12-09 14:10 ` Toke Høiland-Jørgensen [this message]
[not found] ` <CAH2r5msb63LFeDZ9D9dNv8tTS1yS9oLXx8tNqmjTQfXRsKrFzg@mail.gmail.com>
2019-12-09 17:17 ` Toke Høiland-Jørgensen
2019-12-09 20:28 ` Steve French
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87muc1io8r.fsf@toke.dk \
--to=toke@redhat.com \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=smfrench@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.