From patchwork Sun Mar 1 07:10:03 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Emmanuel Grumbach X-Patchwork-Id: 5907061 X-Patchwork-Delegate: johannes@sipsolutions.net Return-Path: X-Original-To: patchwork-linux-wireless@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 568839F440 for ; Sun, 1 Mar 2015 07:10:41 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 76F432041B for ; Sun, 1 Mar 2015 07:10:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 74079203DF for ; Sun, 1 Mar 2015 07:10:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751258AbbCAHKf (ORCPT ); Sun, 1 Mar 2015 02:10:35 -0500 Received: from mga14.intel.com ([192.55.52.115]:49636 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751157AbbCAHKd (ORCPT ); Sun, 1 Mar 2015 02:10:33 -0500 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 28 Feb 2015 23:05:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,670,1418112000"; d="scan'208";a="692231935" Received: from egrumbacbox.jer.intel.com ([10.12.125.42]) by orsmga002.jf.intel.com with ESMTP; 28 Feb 2015 23:10:33 -0800 From: Emmanuel Grumbach To: johannes@sipsolutions.net Cc: linux-wireless@vger.kernel.org, Johannes Berg Subject: [PATCH 04/16] mac80211: fix another suspend vs. association race Date: Sun, 1 Mar 2015 09:10:03 +0200 Message-Id: <1425193815-17785-5-git-send-email-emmanuel.grumbach@intel.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1425193815-17785-1-git-send-email-emmanuel.grumbach@intel.com> References: <1425193815-17785-1-git-send-email-emmanuel.grumbach@intel.com> Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Johannes Berg Since cfg80211 disconnects, but has no insight into the association process, it can happen that it disconnects while association is in progress. We then try to abort association in mac80211, but this is only later so the association can complete between the two. This results in removing an interface from the driver while bound to the channel context, obviously causing confusion and issues. Solve this by also checking if we're associated during quiesce and if so deauthenticating. The frame will no longer go out to the AP which is a bit unfortunate, but it'll resolve the crash (and before we would have suspended without telling the AP as well.) I'm working on a better, but more complex solution as well, which should avoid that problem. Signed-off-by: Johannes Berg --- net/mac80211/mlme.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index cf3ae93..c5f3bd6 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -3985,6 +3985,34 @@ void ieee80211_mgd_quiesce(struct ieee80211_sub_if_data *sdata) IEEE80211_DEAUTH_FRAME_LEN); } + /* This is a bit of a hack - we should find a better and more generic + * solution to this. Normally when suspending, cfg80211 will in fact + * deauthenticate. However, it doesn't (and cannot) stop an ongoing + * auth (not so important) or assoc (this is the problem) process. + * + * As a consequence, it can happen that we are in the process of both + * associating and suspending, and receive an association response + * after cfg80211 has checked if it needs to disconnect, but before + * we actually set the flag to drop incoming frames. This will then + * cause the workqueue flush to process the association response in + * the suspend, resulting in a successful association just before it + * tries to remove the interface from the driver, which now though + * has a channel context assigned ... this results in issues. + * + * To work around this (for now) simply deauth here again if we're + * now connected. + */ + if (ifmgd->associated && !sdata->local->wowlan) { + u8 bssid[ETH_ALEN]; + struct cfg80211_deauth_request req = { + .reason_code = WLAN_REASON_DEAUTH_LEAVING, + .bssid = bssid, + }; + + memcpy(bssid, ifmgd->associated->bssid, ETH_ALEN); + ieee80211_mgd_deauth(sdata, &req); + } + sdata_unlock(sdata); }