Hi Aloka,
> > > 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
