Re: [PATCH 1/1] wireless: mac80211: Avoid using uninitialized stack data
On Wed, 2014-12-10 at 14:14 -0500, jes.soren...@redhat.com wrote: From: Jes Sorensen jes.soren...@redhat.com Avoid case where we would access uninitialized stack data if a driver advertises HT support without 40MHz channel support. ret = IEEE80211_STA_DISABLE_40MHZ; + vht_chandef = *chandef; I think we can and should disable VHT in this case, since VHT requires 40 and 80 MHz support. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] ath10k: fix STA u-APSD
On 10 December 2014 at 13:31, Michal Kazior michal.kaz...@tieto.com wrote:
[...]
@@ -3036,14 +3061,11 @@ static int ath10k_add_interface(struct ieee80211_hw
*hw,
goto err_peer_delete;
}
- param = WMI_STA_PS_PARAM_TX_WAKE_THRESHOLD;
- value = WMI_STA_PS_TX_WAKE_THRESHOLD_ALWAYS;
- ret = ath10k_wmi_set_sta_ps_param(ar, arvif-vdev_id,
- param, value);
+ ret = ath10k_mac_vif_recalc_ps_wake_threshold(arvif);
if (ret) {
- ath10k_warn(ar, failed to set vdev %i TX wake
thresh: %d\n,
+ ath10k_warn(ar, failed to recalc ps wake threshold
on vdev %i: %d\n,
arvif-vdev_id, ret);
- goto err_peer_delete;
+ return ret;
Oops. This is wrong. I should keep the goto.
There are also some Rx performance issues related to excessive PS-Poll usage.
I'll re-spin later.
Michał
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ath10k: Fix no-ack frame status
Sujith Manoharan suj...@msujith.org writes: From: Sujith Manoharan c_man...@qca.qualcomm.com Use the new IEEE80211_TX_STAT_NOACK_TRANSMITTED flag to indicate successful transmission of no-ack frames. This fixes multicast frame accounting. Cc: ath...@lists.infradead.org Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com Johannes, are you planning to take this? Or should I take this once the corresponding mac80211 patch trickles down to my tree? -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] wireless: mac80211: Avoid using uninitialized stack data
From: Jes Sorensen jes.soren...@redhat.com
Disable VHT in case driver advertises HT support without 40MHz+
channel support, in order to avoid accessing uninitialized stack data.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
net/mac80211/mlme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 93af0f1..d7fe2fe 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -173,7 +173,7 @@ ieee80211_determine_chantype(struct ieee80211_sub_if_data
*sdata,
if (!(ht_cap-cap_info
cpu_to_le16(IEEE80211_HT_CAP_SUP_WIDTH_20_40))) {
- ret = IEEE80211_STA_DISABLE_40MHZ;
+ ret = IEEE80211_STA_DISABLE_40MHZ | IEEE80211_STA_DISABLE_VHT;
goto out;
}
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/1] mac80211: Avoid accessing uninitialized stack data
From: Jes Sorensen jes.soren...@redhat.com Hi, Per Johannes' suggestion, here is a v2 of the patch, avoiding accessing uninitialized stack variables when a driver announces HT support without also advertising 40MHz+ support. Cheers, Jes Jes Sorensen (1): wireless: mac80211: Avoid using uninitialized stack data net/mac80211/mlme.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless workshop - was: Netdev 0.1 Call for Proposals
On Wed, 2014-12-03 at 09:24 +0100, Johannes Berg wrote: FWIW, we're planning a wireless summit as a workshop here, which should give us a little more breathing room than e.g. the 3-hour slot at LPC. I'll put up the wiki page and other things and start working on an agenda when I'm back home next week. I've put up a very very very early version of the wiki page here: http://wireless.kernel.org/en/developers/Summits/Ottawa-2015 Please submit topics for the workshop. Wireless-related submissions for the remainder of the conference are also very welcome and encouraged! These would be papers for the remainder of the conference, separate from the discussion topics for the workshop and for the bigger conference audience. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cfg80211: Fix 160 MHz channels with 80+80 and 160 MHz drivers
The VHT supported channel width field is a two bit integer, not a
bitfield. cfg80211_chandef_usable() was interpreting it incorrectly and
ended up rejecting 160 MHz channel width if the driver indicated support
for both 160 and 80+80 MHz channels.
Signed-off-by: Jouni Malinen jo...@qca.qualcomm.com
---
net/wireless/chan.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 85506f1d..7aaf741 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -603,7 +603,7 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
{
struct ieee80211_sta_ht_cap *ht_cap;
struct ieee80211_sta_vht_cap *vht_cap;
- u32 width, control_freq;
+ u32 width, control_freq, cap;
if (WARN_ON(!cfg80211_chandef_valid(chandef)))
return false;
@@ -643,7 +643,8 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
return false;
break;
case NL80211_CHAN_WIDTH_80P80:
- if (!(vht_cap-cap
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ))
+ cap = vht_cap-cap IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK;
+ if (cap != IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ)
return false;
case NL80211_CHAN_WIDTH_80:
if (!vht_cap-vht_supported)
@@ -654,7 +655,9 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
case NL80211_CHAN_WIDTH_160:
if (!vht_cap-vht_supported)
return false;
- if (!(vht_cap-cap IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ))
+ cap = vht_cap-cap IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK;
+ if (cap != IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ
+ cap != IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ)
return false;
prohibited_flags |= IEEE80211_CHAN_NO_160MHZ;
width = 160;
--
1.9.1
--
Jouni MalinenPGP id EFC895FA
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging: rtl8723au: Fix sparse warnings
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
rtw_wlan_util.c:1546:25: warning: cast to restricted __le16
This patch changes declared types of the struct fields involved.
Signed-off-by: Krzysztof Konopko k...@konagma.com
---
drivers/staging/rtl8723au/include/wifi.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723au/include/wifi.h
b/drivers/staging/rtl8723au/include/wifi.h
index fd3da3b..8a2adc5 100644
--- a/drivers/staging/rtl8723au/include/wifi.h
+++ b/drivers/staging/rtl8723au/include/wifi.h
@@ -28,7 +28,7 @@
struct AC_param {
unsigned char ACI_AIFSN;
unsigned char CW;
- unsigned short TXOP_limit;
+ __le16 TXOP_limit;
} __packed;
struct WMM_para_element {
@@ -39,9 +39,9 @@ struct WMM_para_element {
struct ADDBA_request {
unsigned char dialog_token;
- unsigned short BA_para_set;
+ __le16 BA_para_set;
unsigned short BA_timeout_value;
- unsigned short BA_starting_seqctrl;
+ __le16 BA_starting_seqctrl;
} __packed;
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
On 12/11/2014 04:23 PM, Krzysztof Konopko wrote:
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
rtw_wlan_util.c:1546:25: warning: cast to restricted __le16
This patch changes declared types of the struct fields involved.
Signed-off-by: Krzysztof Konopko k...@konagma.com
---
drivers/staging/rtl8723au/include/wifi.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723au/include/wifi.h
b/drivers/staging/rtl8723au/include/wifi.h
index fd3da3b..8a2adc5 100644
--- a/drivers/staging/rtl8723au/include/wifi.h
+++ b/drivers/staging/rtl8723au/include/wifi.h
@@ -28,7 +28,7 @@
struct AC_param {
unsigned char ACI_AIFSN;
unsigned char CW;
- unsigned short TXOP_limit;
+ __le16 TXOP_limit;
} __packed;
struct WMM_para_element {
@@ -39,9 +39,9 @@ struct WMM_para_element {
struct ADDBA_request {
unsigned char dialog_token;
- unsigned short BA_para_set;
+ __le16 BA_para_set;
unsigned short BA_timeout_value;
- unsigned short BA_starting_seqctrl;
+ __le16 BA_starting_seqctrl;
} __packed;
This fix may make the sparse warnings go away, but I think it introduces new
bugs. In particular, did you test on big-endian hardware after you made this
change? I recently found that the driver for RTL8188EU needed to have
BA_para_set to unsigned short, and the endianess warnings needed to be fixed in
the code. Then it would work on my PowerBook G4 with a PPC processor.
In RTL8188EU, both BA_starting_seqctrl and TXOP_limit are unsigned short.
Larry
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
