Hi Aloka,

quoted

quoted

 static int ieee80211_del_iface(struct wiphy *wiphy, struct 
wireless_dev *wdev)
 {
+	struct ieee80211_sub_if_data *sdata = 
IEEE80211_WDEV_TO_SUB_IF(wdev);
+	struct ieee80211_local *local;
+	struct ieee80211_vif *vif;
+
+	if (!sdata)
+		return 0;
+
+	local = sdata->local;
+	vif = &sdata->vif;
+	if (vif->type == NL80211_IFTYPE_AP &&
+	    ieee80211_hw_check(&local->hw, SUPPORTS_MBSSID_AP)) {
+		if (vif->mbssid.flags & IEEE80211_VIF_MBSSID_TX) {
+			struct ieee80211_sub_if_data *child, *tmpsdata;
+
+			wiphy_unlock(local->hw.wiphy);
+			mutex_lock(&local->iflist_mtx);

I really don't think you can drop the locking like that in the middle 
of something. That's almost always a recipe for disaster.

[...]

I'm not able to come up with a different solution which does not cause a 
deadlock by continuing to hold wiphy_lock() as we discussed last time 
that dev_close() will in turn call into cfg80211.

You had suggested looking at dev_close() for VLAN, that code also 
doesn't lock wiphy_lock hence I did same here but locked 
'local->iflist_mtx'. Dropping both won't be good for sure.

Can you please suggest a better way? I'm really not able to come up with 
one.

Yeah, it's a tricky one for sure, especially with the locking changes.

Now that I look at this more closely - the code in ieee80211_del_iface()
must be redundant since the interface has to go through
ieee80211_do_stop() (perhaps during this) if it's actually up?


However, I'm hnsure why you don't understand the VLAN code - see what I
did in commit d5befb224edb ("mac80211: fix deadlock in AP/VLAN
handling")?

johannes