On 09/04/16 23:20, Andriy Voskoboinyk wrote:
There is a rare, but reproducible deadlock for wlan(4) drivers:
* uhub_explore_handle_re_enumerate() (obtains enum_sx lock)
typically <device_stop()> is executed here (prevents
another possible deadlock?)
here it calls ieee80211_stop() and waits for <any> -> INIT state
Thread 2 (started from thread 1):
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
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).
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?
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"