Search Linux Wireless

Re: [PATCH v2] wifi: mac80211: do not abuse fq.lock in ieee80211_do_stop()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/26/22 7:38 AM, Kalle Valo wrote:
(please don't top post, I manually fixed that)

Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> writes:

On 2022/07/18 21:01, Kalle Valo wrote:
Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:

lockdep complains use of uninitialized spinlock at ieee80211_do_stop() [1],
for commit f856373e2f31ffd3 ("wifi: mac80211: do not wake queues on a vif
that is being stopped") guards clear_bit() using fq.lock even before
fq_init() from ieee80211_txq_setup_flows() initializes this spinlock.

According to discussion [2], Toke was not happy with expanding usage of
fq.lock. Since __ieee80211_wake_txqs() is called under RCU read lock, we
can instead use synchronize_rcu() for flushing ieee80211_wake_txqs().

Link: https://syzkaller.appspot.com/bug?extid=eceab52db7c4b961e9d6 [1]
Link: https://lkml.kernel.org/r/874k0zowh2.fsf@xxxxxxx [2]
Reported-by: syzbot <syzbot+eceab52db7c4b961e9d6@xxxxxxxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
Fixes: f856373e2f31ffd3 ("wifi: mac80211: do not wake queues on a vif that is being stopped")
Tested-by: syzbot <syzbot+eceab52db7c4b961e9d6@xxxxxxxxxxxxxxxxxxxxxxxxx>
Acked-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx>

Patch applied to wireless-next.git, thanks.

3598cb6e1862 wifi: mac80211: do not abuse fq.lock in ieee80211_do_stop()

Since this patch fixes a regression introduced in 5.19-rc7, can this patch go to 5.19-final ?

syzbot is failing to test linux.git for 12 days due to this regression.
syzbot will fail to bisect new bugs found in the upcoming merge window
if unable to test v5.19 due to this regression.

I took this to wireless-next as I didn't think there's enough time to
get this to v5.19 (and I only heard Linus' -rc8 plans after the fact).
So this will be in v5.20-rc1 and I recommend pushing this to a v5.19
stable release.

Would it be worth reverting the patch that broke things until the first stable 5.19.x
tree then?  Seems lame to ship an official kernel with a known bug like this.

Thanks,
Ben


--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux