The essid wireless extension does deadlock against the assoc mutex, as we don't unlock the assoc mutex. Signed-off-by: Michael Buesch <mb@xxxxxxxxx> -- This is included in John's wireless-2.6 tree. 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-03-05 18:42:18.000000000 +0100 +++ bu3sch-wireless-dev/net/ieee80211/softmac/ieee80211softmac_wx.c 2007-07-31 14:51:46.000000000 +0200 @@ -98,9 +98,12 @@ 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; + /* Unlock mutex, otherwise we deadlock with the assoc work handler. */ + mutex_unlock(&sm->associnfo.mutex); + flush_scheduled_work(); + mutex_lock(&sm->associnfo.mutex); } } -- 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
