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 :) > Unless we treat the exclude_wdev as "already locked wdev", which I > think is unglier than what I do here. Yeah that doesn't seem right, agree. > > 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. 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
