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:
signature.asc
Description: This is a digitally signed message part
