Re: new lockdep warning in 2.6.31-rc3-wl

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]