> On 4 Dec 2021, at 21:19, Stefan Sperling <[email protected]> wrote: > > 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? >
I think rtm_80211info() could follow the if_link_state_change() way and use task for that.
