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.
