On Tue, Jan 6, 2015 at 12:51 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Mon, 2014-12-29 at 11:59 +0200, Arik Nemtsov wrote: >> If a P2P GO is active, the cfg80211_reg_can_beacon function will take >> the wdev lock, in its call to cfg80211_go_permissive_chan. But the wdev lock >> is already taken by the parent channel-checking function, causing a >> deadlock. >> Split the checking code into two parts. The first part will check if the >> wdev is active and saves the channel under the wdev lock. The second part >> will check actual channel validity according to type. > > 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. Unless we treat the exclude_wdev as "already locked wdev", which I think is unglier than what I do here. > > 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. Arik -- 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
