From: Yogesh Ashok Powar <yogeshp@marvell.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"John W. Linville" <linville@tuxdriver.com>,
Andreas Hartmann <andihartmann@01019freenet.de>
Subject: Re: [PATCH 2/2] mac80211: Fixing Races for skipping tailroom reservation
Date: Wed, 22 Jun 2011 18:01:20 +0530 [thread overview]
Message-ID: <20110622123118.GA4800@hertz.marvell.com> (raw)
In-Reply-To: <20110622071743.GA4087@hertz.marvell.com>
> Will work on some other logic.
Following is the complete V2-patch
v2 changes: a) Moved counter++ before __ieee80211_key_replace in
key_link()
b) Moved crypto_tx_tailroom_needed_cnt to sdata resolve
issue with multiple sdata instances in hw reset.
Thanks
Yogesh
---
net/mac80211/ieee80211_i.h | 3 ++
net/mac80211/key.c | 51 ++++++++++++++++++++++++++++++++++++++++++-
net/mac80211/tx.c | 14 ++++-------
3 files changed, 57 insertions(+), 11 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 090b0ec..74c2f62 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -544,6 +544,9 @@ struct ieee80211_sub_if_data {
/* keys */
struct list_head key_list;
+ /* count for keys needing tailroom space allocation */
+ int crypto_tx_tailroom_needed_cnt;
+
struct net_device *dev;
struct ieee80211_local *local;
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index f825e2f..aea5a71 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -61,6 +61,36 @@ static struct ieee80211_sta *get_sta_for_key(struct ieee80211_key *key)
return NULL;
}
+static void increment_tailroom_need_count(struct ieee80211_sub_if_data *sdata)
+{
+ /*
+ * When this count is zero, SKB resizing for allocating tailroom
+ * for IV or MMIC is skipped. But, this check has created two race
+ * cases in xmit path while transiting from zero count to one:
+ *
+ * 1. SKB resize was skipped because no key was added but just before
+ * the xmit key is added and SW encryption kicks off.
+ *
+ * 2. SKB resize was skipped because all the keys were hw planted but
+ * just before xmit one of the key is deleted and SW encryption kicks
+ * off.
+ *
+ * In both the above case SW encryption will find not enough space for
+ * tailroom and exits with WARN_ON. (See WARN_ONs at wpa.c)
+ *
+ * Solution has been explained at
+ * http://markmail.org/message/c3ykchyv6azzmdum
+ */
+
+ if (!sdata->crypto_tx_tailroom_needed_cnt++) {
+ /*
+ * Flush all XMIT packets currently using HW encryption or no
+ * encryption at all if the count transition is from 0 -> 1.
+ */
+ synchronize_net();
+ }
+}
+
static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
{
struct ieee80211_sub_if_data *sdata;
@@ -101,6 +131,11 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
if (!ret) {
key->flags |= KEY_FLAG_UPLOADED_TO_HARDWARE;
+
+ if (!((key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_MMIC) ||
+ (key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_IV)))
+ sdata->crypto_tx_tailroom_needed_cnt--;
+
return 0;
}
@@ -142,6 +177,10 @@ static void ieee80211_key_disable_hw_accel(struct ieee80211_key *key)
sta = get_sta_for_key(key);
sdata = key->sdata;
+ if (!((key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_MMIC) ||
+ (key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_IV)))
+ increment_tailroom_need_count(sdata);
+
if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
sdata = container_of(sdata->bss,
struct ieee80211_sub_if_data,
@@ -394,8 +433,10 @@ static void __ieee80211_key_destroy(struct ieee80211_key *key)
ieee80211_aes_key_free(key->u.ccmp.tfm);
if (key->conf.cipher == WLAN_CIPHER_SUITE_AES_CMAC)
ieee80211_aes_cmac_key_free(key->u.aes_cmac.tfm);
- if (key->local)
+ if (key->local) {
ieee80211_debugfs_key_remove(key);
+ key->sdata->crypto_tx_tailroom_needed_cnt--;
+ }
kfree(key);
}
@@ -452,6 +493,8 @@ int ieee80211_key_link(struct ieee80211_key *key,
else
old_key = key_mtx_dereference(sdata->local, sdata->keys[idx]);
+ increment_tailroom_need_count(sdata);
+
__ieee80211_key_replace(sdata, sta, pairwise, old_key, key);
__ieee80211_key_destroy(old_key);
@@ -498,8 +541,12 @@ void ieee80211_enable_keys(struct ieee80211_sub_if_data *sdata)
mutex_lock(&sdata->local->key_mtx);
- list_for_each_entry(key, &sdata->key_list, list)
+ sdata->crypto_tx_tailroom_needed_cnt = 0;
+
+ list_for_each_entry(key, &sdata->key_list, list) {
+ increment_tailroom_need_count(sdata);
ieee80211_key_enable_hw_accel(key);
+ }
mutex_unlock(&sdata->local->key_mtx);
}
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 3104c84..e8d0d2d 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1474,18 +1474,14 @@ static bool ieee80211_tx(struct ieee80211_sub_if_data *sdata,
/* device xmit handlers */
-static int ieee80211_skb_resize(struct ieee80211_local *local,
+static int ieee80211_skb_resize(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb,
int head_need, bool may_encrypt)
{
+ struct ieee80211_local *local = sdata->local;
int tail_need = 0;
- /*
- * This could be optimised, devices that do full hardware
- * crypto (including TKIP MMIC) need no tailroom... But we
- * have no drivers for such devices currently.
- */
- if (may_encrypt) {
+ if (may_encrypt && sdata->crypto_tx_tailroom_needed_cnt) {
tail_need = IEEE80211_ENCRYPT_TAILROOM;
tail_need -= skb_tailroom(skb);
tail_need = max_t(int, tail_need, 0);
@@ -1578,7 +1574,7 @@ static void ieee80211_xmit(struct ieee80211_sub_if_data *sdata,
headroom -= skb_headroom(skb);
headroom = max_t(int, 0, headroom);
- if (ieee80211_skb_resize(local, skb, headroom, may_encrypt)) {
+ if (ieee80211_skb_resize(sdata, skb, headroom, may_encrypt)) {
dev_kfree_skb(skb);
rcu_read_unlock();
return;
@@ -1945,7 +1941,7 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
head_need += IEEE80211_ENCRYPT_HEADROOM;
head_need += local->tx_headroom;
head_need = max_t(int, 0, head_need);
- if (ieee80211_skb_resize(local, skb, head_need, true))
+ if (ieee80211_skb_resize(sdata, skb, head_need, true))
goto fail;
}
--
1.5.4.1
next prev parent reply other threads:[~2011-06-22 12:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-16 10:21 [PATCH 0/2] mac80211: Fixing races for hw crypto skipping tailroom Yogesh Ashok Powar
2011-06-16 10:25 ` [PATCH 1/2] Revert "Revert "mac80211: Skip tailroom reservation for full HW-crypto devices"" Yogesh Ashok Powar
2011-06-16 10:27 ` [PATCH 2/2] mac80211: Fixing Races for skipping tailroom reservation Yogesh Ashok Powar
2011-06-16 15:36 ` Johannes Berg
2011-06-17 13:25 ` Yogesh Ashok Powar
2011-06-17 17:24 ` Johannes Berg
2011-06-20 14:30 ` Yogesh Ashok Powar
2011-06-20 15:29 ` Johannes Berg
2011-06-20 16:49 ` Yogesh Powar
2011-06-20 17:29 ` Johannes Berg
2011-06-21 13:03 ` Yogesh Ashok Powar
2011-06-21 13:43 ` Johannes Berg
2011-06-21 14:10 ` Yogesh Ashok Powar
2011-06-21 14:40 ` Johannes Berg
2011-06-21 16:33 ` Yogesh Ashok Powar
2011-06-21 17:44 ` Andreas Hartmann
2011-06-22 7:17 ` Yogesh Ashok Powar
2011-06-22 12:31 ` Yogesh Ashok Powar [this message]
2011-06-22 12:49 ` Johannes Berg
2011-06-22 12:58 ` Yogesh Ashok Powar
2011-06-22 13:12 ` Johannes Berg
2011-06-23 11:52 ` Yogesh Powar
2011-06-24 9:04 ` yogeshp
2011-06-25 13:07 ` Johannes Berg
2011-06-27 6:02 ` [PATCH] nl80211: use netlink consistent dump feature for BSS dumps Walter Goldens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110622123118.GA4800@hertz.marvell.com \
--to=yogeshp@marvell.com \
--cc=andihartmann@01019freenet.de \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).