The essid wireless extension does deadlock against the assoc mutex, as we don't unlock the assoc mutex when flushing the workqueue, which also holds the lock. Signed-off-by: Michael Buesch <mb@xxxxxxxxx> -- This is included in John's wireless-2.6 tree and it sent to Jeff. This doesn't fix the whole issue completely, as we shouldn't flush the workqueue while we are holding the rtnl lock. But, it turns this bug from a "will 100% always deadlock" into a "it might deadlock" bug. A followup patch will come (if someone has some time to do so) to fix this crap code completely. Index: bu3sch-wireless-dev/net/ieee80211/softmac/ieee80211softmac_wx.c =================================================================== --- bu3sch-wireless-dev.orig/net/ieee80211/softmac/ieee80211softmac_wx.c 2007-07-14 18:18:06.000000000 +0200 +++ bu3sch-wireless-dev/net/ieee80211/softmac/ieee80211softmac_wx.c 2007-07-31 20:30:08.000000000 +0200 @@ -74,8 +74,8 @@ ieee80211softmac_wx_set_essid(struct net struct ieee80211softmac_auth_queue_item *authptr; int length = 0; +check_assoc_again: mutex_lock(&sm->associnfo.mutex); - /* Check if we're already associating to this or another network * If it's another network, cancel and start over with our new network * If it's our network, ignore the change, we're already doing it! @@ -98,13 +98,18 @@ ieee80211softmac_wx_set_essid(struct net cancel_delayed_work(&authptr->work); sm->associnfo.bssvalid = 0; sm->associnfo.bssfixed = 0; - flush_scheduled_work(); sm->associnfo.associating = 0; sm->associnfo.associated = 0; + /* We must unlock to avoid deadlocks with the assoc workqueue + * on the associnfo.mutex */ + mutex_unlock(&sm->associnfo.mutex); + flush_scheduled_work(); + /* Avoid race! Check assoc status again. Maybe someone started an + * association while we flushed. */ + goto check_assoc_again; } } - sm->associnfo.static_essid = 0; sm->associnfo.assoc_wait = 0; -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
