On Wed, 2015-01-07 at 15:42 +0200, Arik Nemtsov wrote: > On Wed, Jan 7, 2015 at 3:37 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Wed, 2015-01-07 at 15:34 +0200, Arik Nemtsov wrote: > > > >> > I'm not convinced this is the right thing to do. When checking for the > >> > current wdev that it can use a channel, then it seems that it's own > >> > current BSS connection (if any) shouldn't actually be taken into account > >> > - ergo the lock shouldn't have to be taken, that interface should be > >> > excluded from the "can beacon due to concurrent check" anyway. > >> > >> We have a couple of checks we want to add in the pipeline that also > >> need "this" wdev in the concurrent check, so I'd prefer to avoid this. > > > > Why would you need to check "this" wdev when doing something for "this" > > wdev? Seems odd? But I'm willing to learn :) > > There's some convoluted regulatory logic where if this GO (or any > other) are operating on this GO_CONCURRENT (and not indoor-only) > channel, then it may continue in its operation even after the STA that > operated concurrently has disconnected. Uh, ok, not sure I have that yet... > > > >> > Also, the only reason this can happen anyway is when you call "can > >> > beacon" for a station interface - which seems nonsensical. Given that > >> > >> This is not true. This happens with current code for a p2p-go > >> interface during channel validity checks in reg.c. > > > > Not sure I see this? The only thing doing wdev locking is > > cfg80211_go_permissive_chan(), no? And that only for station interfaces. > > cfg80211_go_permissive_chan is called from cfg80211_reg_can_beacon, > currently only for GO interfaces, but for STA also in the future > (hopefully). > The latter is called during channel validity checks for GO. Ok. Should I just apply the patch as it is then? johannes -- 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
