On Wed, Jan 7, 2015 at 3:37 PM, Johannes Berg <johan...@sipsolutions.net> 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. > >> > 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. Arik -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
