Reinette, Luis,
It's easy to see why this is happening, but I have no easy fix.
> [ 65.053694] phy0/3223 is trying to acquire lock:
> [ 65.053738] (cfg80211_mutex){+.+.+.}, at: [<ffffffffa01c9a72>] regulatory_hint_11d+0x32/0x430 [cfg80211]
> [ 65.053887]
> [ 65.053888] but task is already holding lock:
> [ 65.053968] (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0220f78>] ieee80211_sta_work+0x118/0x11c0 [mac80211]
Clearly, ifmgd->mtx has to be taken from a bunch of cfg80211 calls, but
all calls from cfg80211 into mac80211 hold the cfg80211_mutex.
Now the problem here is that regulatory_hint_11d takes the
cfg80211_mutex.
I looked at two possible solutions:
1) Remove the requirement to hold cfg80211_mutex in cfg80211 for this
function. This is my preferred solution, since I don't think a hint
function should have strange locking constraints. However, the
function accesses a whole bunch of global variables and right now I
don't see how to reduce that, except possibly by allocating and
queueing new work struct, but then I don't see how to cancel that
work struct when the wiphy is unregistered while it might be pending.
2) Move the regulatory_hint_11d call outside the ifmgd->mtx locked
section. This isn't nice, as it means we require more effort from the
callers. Also, I think it's not sufficient, because mac80211 has to
cancel_work_sync() the sta work, which would be calling this, when an
interface is taken down --- BUT taking down an interface can happen,
when it's simply removed with nl80211 (!), within cfg80211 context,
and as such again under the lock, which has the same problem.
3) Remove the regulatory_hint_11d function (or rather make it not
exported), and instead pass the country IE (or the whole beacon
frame) to regulatory_hint_found_beacon(), and process it all from the
regulatory work that hint_found_beacon queues. That also reduces the
number of entry points from drivers, and means that if the driver
uses cfg80211-based scanning, it also automatically takes part in the
regulatory infrastructure. Win.
Obviously 3) is my favourite solution, not only because it's the only
one that seems feasible at all, but it's somewhat more complex, and I
don't really have time to do that today.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
