Deadlock between device_detach() and usbd_do_request_flags()
Hans Petter Selasky
hps at selasky.org
Mon Sep 5 07:48:29 UTC 2016
On 09/04/16 23:20, Andriy Voskoboinyk wrote:
> There is a rare, but reproducible deadlock for wlan(4) drivers:
>
> Thread 1:
> * uhub_explore_handle_re_enumerate() (obtains enum_sx lock)
> * usbd_set_config_index()
> * usb_unconfigure()
> * usb_detach_device()
> * usb_detach_device_sub()
> * <device_detach()>
> typically <device_stop()> is executed here (prevents
> another possible deadlock?)
> * ieee80211_ifdetach()
> * ieee80211_vap_destroy()
> * <ic->ic_vap_delete>
> * ieee80211_vap_detach()
> here it calls ieee80211_stop() and waits for <any> -> INIT state
> transition
>
> Thread 2 (started from thread 1):
> * ieee80211_newstate_cb()
> * vap->iv_newstate()
> here: if the driver will try to call usbd_do_request_flags()
> (typically via <drv_write_reg> / <drv_read_reg>) it will hang
> (because enum_sx lock is already held by thread 1).
>
>
> Another way: execute some periodical task that will try to access
> some registers (urtwn_temp_calib(), rum_ratectl_task(),
> run_ratectl_cb()) while thread 1 is running - deadlock is
> here too, since <device_detach> will wait for them indefinitely
> (via ieee80211_draintask())
>
> Right now the most obvious (and, probably, wrong) way is to just
> detect & release all locks (usbd_enum_unlock()) for
> ieee80211_ifdetach() / ieee80211_draintask() and re-acquire them
> later (not tested yet).
>
Hi,
I think the right solution is to let usbd_do_request_flags() use its own
SX lock for synchronization, instead of re-using the enumeration SX
lock. What do you think about that?
--HPS
More information about the freebsd-wireless
mailing list