Date: Wed, 14 Feb 2024 19:50:23 +0000 From: bugzilla-noreply@freebsd.org To: wireless@FreeBSD.org Subject: [Bug 275255] iwlwifi: panic after iwlwifi0: lkpi_iv_newstate: error -5 during state transition 5 (RUN) -> 0 (INIT) Message-ID: <bug-275255-21060-6QHd2QxbK4@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-275255-21060@https.bugs.freebsd.org/bugzilla/> References: <bug-275255-21060@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275255 --- Comment #4 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D713db49d06deee90dd358b2e4b9ca0536= 8a5eaf6 commit 713db49d06deee90dd358b2e4b9ca05368a5eaf6 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2024-01-10 10:14:16 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2024-02-14 19:47:21 +0000 net80211: deal with lost state transitions Since 5efea30f039c4 we can possibly lose a state transition which can cause trouble further down the road. The reproducer from 643d6dce6c1e can trigger these for example. Drivers for firmware based wireless cards have worked around some of this (and other) problems in the past. Add an array of tasks rather than a single one as we would simply get npending > 1 and lose order with other tasks. Try to keep state changes updated as queued in case we end up with more than one at a time. While this is not ideal either (call it a hack) it will sort the problem for now. We will queue in ieee80211_new_state_locked() and do checks there and dequeue in ieee80211_newstate_cb(). If we still overrun the (currently) 8 slots we will drop the state change rather than overwrite the last one. When dequeing we will update iv_nstate and keep it around for historic reasons for the moment. The longer term we should make the callers of ieee80211_new_state[_locked]() actually use the returned errors and act appropriately but that will touch a lot more places and drivers (possibly incl. changed behaviour for ioctls). rtwn(4) and rum(4) should probably be revisted and net80211 internals removed (for rum(4) at least the current logic still seems prone to races). PR: 271979, 271988, 275255, 263613, 274003 Sponsored by: The FreeBSD Foundation (in 2023) MFC after: 3 days Reviewed by: cc Differential Revision: https://reviews.freebsd.org/D43389 sys/dev/rtwn/if_rtwn.c | 4 +- sys/dev/usb/wlan/if_rum.c | 4 +- sys/net80211/ieee80211.c | 4 +- sys/net80211/ieee80211_ddb.c | 13 ++++- sys/net80211/ieee80211_proto.c | 124 ++++++++++++++++++++++++++++++++++---= ---- sys/net80211/ieee80211_var.h | 13 ++++- 6 files changed, 134 insertions(+), 28 deletions(-) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-275255-21060-6QHd2QxbK4>