On Thu, Feb 12, 2009 at 11:17 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Thu, 2009-02-12 at 23:14 -0800, Luis R. Rodriguez wrote: > >> >>> Yes, but I need to look at the one Reinette posted and fix that one, >> >>> which will probably require a different solution. >> >> >> >> Oh I didn't see that one. How different? >> > >> > I see an rtnl lock issue against scanning and the drv mutex. Doesn't >> > seem to be related to regulatory. So how would that affect a path to >> > move hints to a workqueue? >> >> Oh you mean the rntl_lock() and drv mutex is _still_ an issue? > > Well, regardless of regulatory, we now have two paths: > > nl80211: cfg80211_mutex --> drv->mutex --> rtnl > wext: rtnl --> cfg80211_mutex --> drv->mutex > > which is clearly not a good plan. > > Therefore, I'll probably have to implement solution (1) from what I sent > you, and invert the locking in nl80211. That would fix your the > immediate problem with regulatory as well, because that was: > > rtnl ---> (regulatory_hint) ---> cfg80211_mutex --> drv->mutex Yup I see. So as it stands in this patch user reg hint now is: reg_mutex --> cfg80211_mutex Driver hint also does the same so it seems your fix on nl80211 would probably just tap this series on the nl80211_req_set_reg(). I also think using a workqueue would be good here anyway, the only negative thing I've seen is loading takes a bit longer. Luis -- 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
