Re: SME warning on 2.6.32-rc<bleh>

[Johannes Berg <johannes@sipsolutions.net>]

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

On Tue, 2009-09-29 at 12:24 -0700, Luis R. Rodriguez wrote:
> I believe the problem comes from the assumption from cfg80211 that
> previous deauthentications would have gone through before we run
> __cfg80211_disconnected() and are using wext or nl80211
> connec/disconnectt. Under certain conditions (clearly not known yet)
> this is not true and we'll end up asking mac80211 to deauthenticate us
> from a BSS we already deauthenticated to end end up with an -ENOLINK
> on our mac80211 cfg80211 deauth ops. It seems this race was expected
> all along on mac80211 ieee80211_mgd_deauth():
> 
>         /*
>          * cfg80211 should catch this ... but it's racy since
>          * we can receive a deauth frame, process it, hand it
>          * to cfg80211 while that's in a locked section already
>          * trying to tell us that the user wants to disconnect.
>          */
>         if (!bssid) {
>                 mutex_unlock(&ifmgd->mtx);
>                 return -ENOLINK;
>         }
> 
> So it seems we do need to address that race but I'm not yet sure how.

I don't think so. The race is definitely there in mac80211, but not in
cfg80211, since both processing the deauth frame and sending a deauth
frame in cfg80211 are both under the same lock.

OTOH, it could happen with lock contention, but that seems very unlikely
here?

I mean -- this race should only happen if the AP and you decide to
deauth at the /same/ time. Precisely the same time.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]