On Thu, Nov 11, 2010 at 10:05:21PM -0800, Mark Mentovai wrote: > Luis R. Rodriguez wrote: > > When two cards are connected with the same regulatory domain > > if CRDA had a delayed response then cfg80211's own set regulatory > > domain would still be the world regulatory domain. There was a bug > > on cfg80211's ignore_request() when analyzing incoming driver > > regulatory hints as it was only checking against the currently > > set cfg80211 regulatory domain and not for any other new > > pending requests. This is easily fixed by also checking against > > the pending request. > > Luis, thanks for taking a look at this bug. > > Capsule summary: youâve overloaded -EALREADY, which until now seemed > to mean âthatâs the regdomain Iâm already using,â to now also mean > âIâm going to be using that regdomain soon but Iâm waiting on CRDA.â > The two cases need to be handled differently. > > In my case, this patch makes things a little bit worse. I tested it > with compat_wireless 20101110. Iâve included what I see after boot > below the explanation. > > Your patch changes things so that, according to the steps in my > original message, steps 3 and 4 become: > > 3. The second cardâs driver calls regulatory_hint to provide US as a > driver hint. ignore_request sees that the last request came from a > driver and that the current and last request sought to set the same > hint, so it returns -EALREADY. This triggers the âif the regulatory > domain being requested by the driverâ block, which calls reg_copy_regd > on the apparent assumption that cfg80211_regdomain contains the > regdomain that the wiphy actually wants, although it doesnât, and itâs > very wrong to do this copy. cfg80211_regdomain is still on 00, because > CRDA hasnât responded to the first cardâs request yet. > > 4. When CRDA finally responds to the first cardâs request from #2, it > gets plumbed to set_regdom, which calls __set_regdom. __set_regdom > sees that itâs not intersecting, and enters the block where it would > normally copy reg_copy_regd to set the wiphyâs regd, but the wiphy it > uses is the one saved from last_request (in step 3), and it already > had something copied to it (also in step 3). Since __set_regdom checks > for this and bails out with -EALREADY in the âuserspace could have > sent two replies with only one kernel requestâ case. Because > __set_regdom fails, set_regdom returns early and never makes it to the > update_all_wiphy_regulatory or print_regdomain steps. The regdomain > remains unchanged. Iâm still stuck at 00. > > What about using something other than -EALREADY to signal âthat > request is already pending?â On its face, this works, but I think > thereâs a deeper flaw that also needs to be addressed. Iâm concerned > that the wiphys that fall into this state wonât see a reg_copy_regd > call at all. The idea is that any such wiphy shouldnât really be > ignored, but it should be joined to a group of wiphys waiting on the > pending request, and when the request is satisfied, the regd field > should be populated for each of them. Thanks for testing and your review. We need to address a queue of requests with the associated wiphys, as I originally had developed, I'll go ahead and add this and treat these, it should take care of even multiple cards with different regulatory hints. I expect the amount of code will be a bit to large for stable though so likely we may only be able to fix this for new kernels. I'll take a stab at this now. 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
