Deadlock between device_detach() and usbd_do_request_flags()

Andriy Voskoboinyk avos at freebsd.org
Sun Sep 4 21:29:01 UTC 2016


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).

Any ideas?


More information about the freebsd-usb mailing list