On Sat, Dec 04, 2021 at 07:06:35PM +0100, Tobias Heider wrote: > On Sat, Dec 04, 2021 at 06:50:54PM +0100, Stefan Sperling wrote: > > On Sat, Dec 04, 2021 at 10:37:53AM -0600, Scott Cheloha wrote: > > > Hit a witness panic during boot yesterday. Can't repro, have never > > > seen it before. The photo is a mess (ask if you want it) but the > > > backtrace is: > > > > > > panic > > > witness_checkorder > > > rw_enter_write > > > solock > > > route input > > > ieee80211_set_link_state > > > ieee80211_recv_4way_msg3 > > > ieee80211_eapol_key_input > > > ieee80211_decap > > > ieee80211_input_ba_flush > > > ieee80211_input_ba_gap_timeout > > > timeout_run > > > softclock_process_tick_timeout > > > sotclock > > > > > > We're not allowed to take sleeping locks during the execution of a > > > timeout, hence the witness panic. > > > > I was under the impression that timeouts and tasks are equivalent in this > > respect. Do timeouts not use a process context which can use rw locks? > > Was this never the case? Or did this change recently? > > > > We could schedule a task from the BA gap timeout handler, there is > > no problem with doing that. > > > > However, there are many callers of ieee80211_set_link_state(), including > > drivers. And in particular the WPA handshake will usually be triggered > > from interrupt context as frames are received, and call into this function. > > > > If ieee80211_set_link_state() now requires a context which can sleep > > we should really be checking all its callers for similar issues... > > > > Or we stop using a routing message and invent another mechanism that > > will work within the current requirements of the wireless stack? > > > > I think timeout_set_proc() might be what you are looking for.
For this particular case, yes. But that won't solve ieee80211_set_link_state() being called from interrupt context, would it?
