On Mon, Feb 14, 2011 at 12:09 PM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
> On Tue, 2011-02-08 at 18:43 +0200, Eliad Peller wrote:
>> When suspending an associated system, and then resuming,
>> the station vif is being reconfigured without taking the
>> sdata->u.mgd.mtx lock, which results in the following warning:
>
> ...
>
>> net/mac80211/util.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
>> index cf68700..d036597 100644
>> --- a/net/mac80211/util.c
>> +++ b/net/mac80211/util.c
>> @@ -1210,7 +1210,9 @@ int ieee80211_reconfig(struct ieee80211_local *local)
>> switch (sdata->vif.type) {
>> case NL80211_IFTYPE_STATION:
>> changed |= BSS_CHANGED_ASSOC;
>> + mutex_lock(&sdata->u.mgd.mtx);
>> ieee80211_bss_info_change_notify(sdata, changed);
>> + mutex_unlock(&sdata->u.mgd.mtx);
>> break;
>> case NL80211_IFTYPE_ADHOC:
>> changed |= BSS_CHANGED_IBSS;
>
> Oi, this is a complicated locking rule.
>
> Can you please stick a
>
> lockdep_assert_held(...)
>
> in the right place to make sure we catch it even on drivers that don't
> use the probe_req function?
>
well, i'm not sure what is the right place / when this mutex should be taken.
when doing something like:
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 1c507c6..ab1843d 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -191,6 +191,7 @@ void ieee80211_bss_info_change_notify(struct
ieee80211_sub_if_data *sdata,
return;
if (sdata->vif.type == NL80211_IFTYPE_STATION) {
+ lockdep_assert_held(&sdata->u.mgd.mtx);
/*
* While not associated, claim a BSSID of all-zeroes
* so that drivers don't do any weird things with the
i got several warnings from ieee80211_open, ieee80211_recalc_idle, etc.
should this mutex be taken if the psm has been changed (for example)?
or should we check the mutex only if certain flags has been changed?
Eliad.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
