On Sat, Dec 04, 2021 at 07:19:23PM +0100, Stefan Sperling wrote: > For this particular case, yes. > But that won't solve ieee80211_set_link_state() being called from > interrupt context, would it?
Below is a breakdown of all callers by context. I grepped for direct callers. My search did not see indirect callers such as the one from timeout context which we already know about. I am worried about callers in interrupt context. It will be hard to "fix" some of these. I would prefer if the routing message layer could be made to work from interrupt context if possible. Is there a function we could call to figure out which context we are running in? If so, ieee80211_set_link_state() could skip sending the routing message as a workaround. This means some drivers would lose link state messages unless relevant driver code is migrated to a task. Which could be done over time on demand, on a per-driver basis. autoconf context (no userland yet so doesn't matter): ieee80211_ifattach() interrupt context (bad): bwfm_newstate() pgt_newstate() ipw_newstate() iwi_newstate() iwn_newstate() wpi_newstate() atu_newstate() ieee80211_recv_4way_msg3() ieee80211_recv_rsn_group_msg1() ieee80211_recv_wpa_group_msg1() ieee80211_newstate() <<-- ALL DRIVERS go through here task context (ok): iwm_scan() iwx_scan() iwx_add_sta_key() athn_usb_set_key_cb() otus_set_key_cb() rsu_set_key_cb() run_set_key_cb() urtwn_set_key_cb()
