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?
