On Fri, May 14, 2021 at 10:26:25AM +0200, Johannes Berg wrote:
> If that's all not solving the issue then please try to resolve with gdb
> what line of code "cfg80211_netdev_notifier_call+0x12a" is, and please
> also clarify exactly what (upstream!) kernel you're using.
I can reproduce on v5.12 and v5.12.4 as well. With v5.12.4, I'm at:
net/wireless/core.c:
1428 wiphy_lock(&rdev->wiphy);
include/net/cfg80211.h:
5269 mutex_lock(&wiphy->mtx);
i.e.,
static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
unsigned long state, void *ptr)
{
...
case NETDEV_GOING_DOWN:
wiphy_lock(&rdev->wiphy); <--- right here
cfg80211_leave(rdev, wdev);
wiphy_unlock(&rdev->wiphy);
...
It would seem like _anyone_ that calls cfg80211_unregister_wdev() with
an interface up will hit this -- not unique to mwifiex. In fact, apart
from the fact that all his line numbers are wrong, Maximilian's original
email points out exactly where the deadlock is.
cfg80211_unregister_wdev() holds the wiphy lock, and the GOING_DOWN
notification also tries to grab it.
It does happen that in many other paths, you've already ensured that you
bring the interface down, so e.g., mac80211 drivers don't tend to hit
this. But I wouldn't be surprised if a few other cfg80211 drivers hit
this too.
The best solution I could figure was to do a similar lock dance done in
nl80211_del_interface() -- close the netdev without holding the wiphy
lock. I'll send out a patch shortly.
Brian
