Re: [PATCH] Clear subdir_stations when stations directory is removed (was Re: Null pointer dereference when station associates [introduced by 4.0.5?])
On Mon, 2015-06-29 at 19:41 +0100, Tom Hughes wrote: On 29/06/15 11:28, Tom Hughes wrote: On 29/06/15 11:24, Tom Hughes wrote: So I think this happens when hostapd switches the interface to AP mode, which causes the netdev to be torn down and then recreated, and the debugfs directory along with it. Except that if the netlink message to change the mode was sent from a daemon whose selinux context prevents searching debugfs the recreation somehow fails and leaves an invalid state that later causes the null pointer deref. Think I have it... The teardown runs ieee80211_debugfs_remove_netdev which clears sdata-vif.debugfs_dir but does not clear sdata-debugfs.subdir_stations so that when ieee80211_debugfs_add_netdev later fails to create the top level netdev directory we are left with a bogus pointer for the stations directory. Then when we try and add an entry to the stations directory things blow up. Here's a proposed patch. I have booted 4.0.6 with this applied and so far it hasn't failed even with selinux in enforcing mode. commit 30624496e9f411081d7ea1a407deabe0e32d0c62 Author: Tom Hughes t...@compton.nu Date: Mon Jun 29 11:31:04 2015 +0100 Clear subdir_stations when stations directory is removed If we don't do this, and we then fail to recreate the debugfs directory during a mode change, then we will fail later trying to add stations to this now bogus directory: BUG: unable to handle kernel NULL pointer dereference at 006c IP: [c0a92202] mutex_lock+0x12/0x30 Call Trace: [c0678ab4] start_creating+0x44/0xc0 [c0679203] debugfs_create_dir+0x13/0xf0 [f8a938ae] ieee80211_sta_debugfs_add+0x6e/0x490 [mac80211] Signed-off-by: Tom Hughes t...@compton.nu Applied. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Null pointer dereference when station associates [introduced by 4.0.5?]
On Sat, 2015-06-27 at 16:34 +0100, Tom Hughes wrote: Interestingly from what I can see this is trying to create a file for the station at a path something like: ieee80211/phy0/netdev:/stations/XX indeed. but in my (currently working) boot under 4.0.4 there is no netdev directory under phy0 in debugfs... but then maybe that is the problem as well if the inode pointer was null? This is pretty strange - if the dentry pointer (sdata -debugfs.subdir_stations) was NULL or an ERR_PTR(), the code would return pretty much immediately. So it looks like that pointer is valid, but it's -d_inode was NULL? I'm not really sure how that could happen. Since 4.0.4 was stable, and 4.0.5 crashes, you'd think there's something wrong between those two kernels and there were no changes to mac80211 related to these code paths in there. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: enable assoc check for mesh interfaces
On Sat, 2015-06-13 at 10:16 -0400, Bob Copeland wrote: We already set a station to be associated when peering completes, both in user space and in the kernel. Thus we should always have an associated sta before sending data frames to that station. Failure to check assoc state can cause crashes in the lower-level driver due to transmitting unicast data frames before driver sta structures (e.g. ampdu state in ath9k) are initialized. This occurred when forwarding in the presence of fixed mesh paths: frames were transmitted to stations with whom we hadn't yet completed peering. Applied. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211: avoid mem leak on driver hint set
On Thu, 2014-12-04 at 12:22 +0200, Arik Nemtsov wrote: In the already-set and intersect case of a driver-hint, the previous wiphy regdomain was not freed before being reset with a copy of the cfg80211 regdomain. Applied. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211: don't WARN about two consecutive Country IE hint
On Tue, 2014-12-02 at 09:53 +0200, Emmanuel Grumbach wrote: This can happen and there is no point in added more detection code lower in the stack. Catching these in one single point (cfg80211) is enough. Stop WARNING about this case. Applied. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.14] mac80211: Fix regression that triggers a kernel BUG with CCMP
From: Johannes Berg johannes.b...@intel.com Upstream commit 4f031fa9f188b2b0641ac20087d9e16bcfb4e49d. Commit 7ec7c4a9a686c608315739ab6a2b0527a240883c (mac80211: port CCMP to cryptoapi's CCM driver) introduced a regression when decrypting empty packets (data_len == 0). This will lead to backtraces like: (scatterwalk_start) from [c01312f4] (scatterwalk_map_and_copy+0x2c/0xa8) (scatterwalk_map_and_copy) from [c013a5a0] (crypto_ccm_decrypt+0x7c/0x25c) (crypto_ccm_decrypt) from [c032886c] (ieee80211_aes_ccm_decrypt+0x160/0x170) (ieee80211_aes_ccm_decrypt) from [c031c628] (ieee80211_crypto_ccmp_decrypt+0x1ac/0x238) (ieee80211_crypto_ccmp_decrypt) from [c032ef28] (ieee80211_rx_handlers+0x870/0x1d24) (ieee80211_rx_handlers) from [c0330c7c] (ieee80211_prepare_and_rx_handle+0x8a0/0x91c) (ieee80211_prepare_and_rx_handle) from [c0331260] (ieee80211_rx+0x568/0x730) (ieee80211_rx) from [c01d3054] (__carl9170_rx+0x94c/0xa20) (__carl9170_rx) from [c01d3324] (carl9170_rx_stream+0x1fc/0x320) (carl9170_rx_stream) from [c01cbccc] (carl9170_usb_tasklet+0x80/0xc8) (carl9170_usb_tasklet) from [c00199dc] (tasklet_hi_action+0x88/0xcc) (tasklet_hi_action) from [c00193c8] (__do_softirq+0xcc/0x200) (__do_softirq) from [c0019734] (irq_exit+0x80/0xe0) (irq_exit) from [c0009c10] (handle_IRQ+0x64/0x80) (handle_IRQ) from [c000c3a0] (__irq_svc+0x40/0x4c) (__irq_svc) from [c0009d44] (arch_cpu_idle+0x2c/0x34) Such packets can appear for example when using the carl9170 wireless driver because hardware sometimes generates garbage when the internal FIFO overruns. This patch adds an additional length check. Cc: stable@vger.kernel.org Fixes: 7ec7c4a9a686 (mac80211: port CCMP to cryptoapi's CCM driver) Acked-by: Ard Biesheuvel ard.biesheu...@linaro.org Signed-off-by: Ronald Wahl ronald.w...@raritan.com Signed-off-by: Johannes Berg johannes.b...@intel.com --- net/mac80211/aes_ccm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c index 7c7df475a401..f056f9ed97fb 100644 --- a/net/mac80211/aes_ccm.c +++ b/net/mac80211/aes_ccm.c @@ -54,6 +54,9 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, memset(aead_req, 0, sizeof(aead_req)); + if (data_len == 0) + return -EINVAL; + sg_init_one(pt, data, data_len); sg_init_one(assoc, aad[2], be16_to_cpup((__be16 *)aad)); sg_init_table(ct, 2); -- 2.1.1 -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mac80211: fix typo in starting baserate for rts_cts_rate_idx
On Mon, 2014-10-13 at 14:34 +0200, Karl Beldan wrote: From: Karl Beldan karl.bel...@rivierawaves.com It affects non-(V)HT rates and can lead to selecting an rts_cts rate that is not a basic rate or way superior to the reference rate (ATM rates[0] used for the 1st attempt of the protected frame data). Applied. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.10] nl80211: clear skb cb before passing to netlink
From: Johannes Berg johannes.b...@intel.com
Upstream commit bd8c78e78d5011d8111bc2533ee73b13a3bd6c42.
In testmode and vendor command reply/event SKBs we use the
skb cb data to store nl80211 parameters between allocation
and sending. This causes the code for CONFIG_NETLINK_MMAP
to get confused, because it takes ownership of the skb cb
data when the SKB is handed off to netlink, and it doesn't
explicitly clear it.
Clear the skb cb explicitly when we're done and before it
gets passed to netlink to avoid this issue.
Cc: stable@vger.kernel.org [this goes way back]
Reported-by: Assaf Azulay assaf.azu...@intel.com
Reported-by: David Spinadel david.spina...@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/wireless/nl80211.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 448c034184e2..62aebed7c6e2 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6568,6 +6568,9 @@ int cfg80211_testmode_reply(struct sk_buff *skb)
void *hdr = ((void **)skb-cb)[1];
struct nlattr *data = ((void **)skb-cb)[2];
+ /* clear CB data for netlink core to own from now on */
+ memset(skb-cb, 0, sizeof(skb-cb));
+
if (WARN_ON(!rdev-testmode_info)) {
kfree_skb(skb);
return -EINVAL;
@@ -6594,6 +6597,9 @@ void cfg80211_testmode_event(struct sk_buff *skb, gfp_t
gfp)
void *hdr = ((void **)skb-cb)[1];
struct nlattr *data = ((void **)skb-cb)[2];
+ /* clear CB data for netlink core to own from now on */
+ memset(skb-cb, 0, sizeof(skb-cb));
+
nla_nest_end(skb, data);
genlmsg_end(skb, hdr);
genlmsg_multicast_netns(wiphy_net(rdev-wiphy), skb, 0,
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.14] Revert mac80211: move bufferable MMPDU check to fix AP mode scan
From: Johannes Berg johannes.b...@intel.com
Upstream commit 08b9939997df30e42a228e1ecb97f99e9c8ea84e, adjusted for
lack of ieee80211_is_bufferable_mmpdu() helper function.
This reverts commit 277d916fc2e959c3f106904116bb4f7b1148d47a as it was
at least breaking iwlwifi by setting the IEEE80211_TX_CTL_NO_PS_BUFFER
flag in all kinds of interface modes, not only for AP mode where it is
appropriate.
To avoid reintroducing the original problem, explicitly check for probe
request frames in the multicast buffering code.
Cc: stable@vger.kernel.org
Fixes: 277d916fc2e9 (mac80211: move bufferable MMPDU check to fix AP mode
scan)
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/tx.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index c14c16a6d62d..e5a7ac2f3687 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -414,6 +414,9 @@ ieee80211_tx_h_multicast_ps_buf(struct ieee80211_tx_data
*tx)
if (ieee80211_has_order(hdr-frame_control))
return TX_CONTINUE;
+ if (ieee80211_is_probe_req(hdr-frame_control))
+ return TX_CONTINUE;
+
if (tx-local-hw.flags IEEE80211_HW_QUEUE_CONTROL)
info-hw_queue = tx-sdata-vif.cab_queue;
@@ -464,6 +467,7 @@ ieee80211_tx_h_unicast_ps_buf(struct ieee80211_tx_data *tx)
{
struct sta_info *sta = tx-sta;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx-skb);
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx-skb-data;
struct ieee80211_local *local = tx-local;
if (unlikely(!sta))
@@ -474,6 +478,15 @@ ieee80211_tx_h_unicast_ps_buf(struct ieee80211_tx_data *tx)
!(info-flags IEEE80211_TX_CTL_NO_PS_BUFFER))) {
int ac = skb_get_queue_mapping(tx-skb);
+ /* only deauth, disassoc and action are bufferable MMPDUs */
+ if (ieee80211_is_mgmt(hdr-frame_control)
+ !ieee80211_is_deauth(hdr-frame_control)
+ !ieee80211_is_disassoc(hdr-frame_control)
+ !ieee80211_is_action(hdr-frame_control)) {
+ info-flags |= IEEE80211_TX_CTL_NO_PS_BUFFER;
+ return TX_CONTINUE;
+ }
+
ps_dbg(sta-sdata, STA %pM aid %d: PS buffer for AC %d\n,
sta-sta.addr, sta-sta.aid, ac);
if (tx-local-total_ps_buffered = TOTAL_MAX_TX_BUFFER)
@@ -532,22 +545,8 @@ ieee80211_tx_h_unicast_ps_buf(struct ieee80211_tx_data *tx)
static ieee80211_tx_result debug_noinline
ieee80211_tx_h_ps_buf(struct ieee80211_tx_data *tx)
{
- struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx-skb);
- struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx-skb-data;
-
if (unlikely(tx-flags IEEE80211_TX_PS_BUFFERED))
return TX_CONTINUE;
-
- /* only deauth, disassoc and action are bufferable MMPDUs */
- if (ieee80211_is_mgmt(hdr-frame_control)
- !ieee80211_is_deauth(hdr-frame_control)
- !ieee80211_is_disassoc(hdr-frame_control)
- !ieee80211_is_action(hdr-frame_control)) {
- if (tx-flags IEEE80211_TX_UNICAST)
- info-flags |= IEEE80211_TX_CTL_NO_PS_BUFFER;
- return TX_CONTINUE;
- }
-
if (tx-flags IEEE80211_TX_UNICAST)
return ieee80211_tx_h_unicast_ps_buf(tx);
else
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.10] Revert mac80211: move bufferable MMPDU check to fix AP mode scan
From: Johannes Berg johannes.b...@intel.com
Upstream commit 08b9939997df30e42a228e1ecb97f99e9c8ea84e, adjusted for
lack of ieee80211_is_bufferable_mmpdu() helper function.
This reverts commit 277d916fc2e959c3f106904116bb4f7b1148d47a as it was
at least breaking iwlwifi by setting the IEEE80211_TX_CTL_NO_PS_BUFFER
flag in all kinds of interface modes, not only for AP mode where it is
appropriate.
To avoid reintroducing the original problem, explicitly check for probe
request frames in the multicast buffering code.
Cc: stable@vger.kernel.org
Fixes: 277d916fc2e9 (mac80211: move bufferable MMPDU check to fix AP mode
scan)
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/tx.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index d566cdba24ec..10eea2326022 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -398,6 +398,9 @@ ieee80211_tx_h_multicast_ps_buf(struct ieee80211_tx_data
*tx)
if (ieee80211_has_order(hdr-frame_control))
return TX_CONTINUE;
+ if (ieee80211_is_probe_req(hdr-frame_control))
+ return TX_CONTINUE;
+
/* no stations in PS mode */
if (!atomic_read(ps-num_sta_ps))
return TX_CONTINUE;
@@ -447,6 +450,7 @@ ieee80211_tx_h_unicast_ps_buf(struct ieee80211_tx_data *tx)
{
struct sta_info *sta = tx-sta;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx-skb);
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx-skb-data;
struct ieee80211_local *local = tx-local;
if (unlikely(!sta))
@@ -457,6 +461,15 @@ ieee80211_tx_h_unicast_ps_buf(struct ieee80211_tx_data *tx)
!(info-flags IEEE80211_TX_CTL_NO_PS_BUFFER))) {
int ac = skb_get_queue_mapping(tx-skb);
+ /* only deauth, disassoc and action are bufferable MMPDUs */
+ if (ieee80211_is_mgmt(hdr-frame_control)
+ !ieee80211_is_deauth(hdr-frame_control)
+ !ieee80211_is_disassoc(hdr-frame_control)
+ !ieee80211_is_action(hdr-frame_control)) {
+ info-flags |= IEEE80211_TX_CTL_NO_PS_BUFFER;
+ return TX_CONTINUE;
+ }
+
ps_dbg(sta-sdata, STA %pM aid %d: PS buffer for AC %d\n,
sta-sta.addr, sta-sta.aid, ac);
if (tx-local-total_ps_buffered = TOTAL_MAX_TX_BUFFER)
@@ -514,22 +527,8 @@ ieee80211_tx_h_unicast_ps_buf(struct ieee80211_tx_data *tx)
static ieee80211_tx_result debug_noinline
ieee80211_tx_h_ps_buf(struct ieee80211_tx_data *tx)
{
- struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx-skb);
- struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx-skb-data;
-
if (unlikely(tx-flags IEEE80211_TX_PS_BUFFERED))
return TX_CONTINUE;
-
- /* only deauth, disassoc and action are bufferable MMPDUs */
- if (ieee80211_is_mgmt(hdr-frame_control)
- !ieee80211_is_deauth(hdr-frame_control)
- !ieee80211_is_disassoc(hdr-frame_control)
- !ieee80211_is_action(hdr-frame_control)) {
- if (tx-flags IEEE80211_TX_UNICAST)
- info-flags |= IEEE80211_TX_CTL_NO_PS_BUFFER;
- return TX_CONTINUE;
- }
-
if (tx-flags IEEE80211_TX_UNICAST)
return ieee80211_tx_h_unicast_ps_buf(tx);
else
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.14] iwlwifi: mvm: delay enabling smart FIFO until after beacon RX
From: Johannes Berg johannes.b...@intel.com
Upstream commit 0229cdafb6f67064a217591d48b0f6abf14e8385.
If we have no beacon data before association, delay smart FIFO
enablement until after we have this data.
Not doing so can cause association failures in extremely silent
environments (usually only a shielded box/room) as beacon RX is
not sent to the host immediately, and then the association time
event ends without the host receiving any beacon even though it
was on the air - it's just stuck on the FIFO.
Cc: stable@vger.kernel.org [3.14]
Fixes: 1f3b0ff8ecce (iwlwifi: mvm: Add Smart FIFO support)
Signed-off-by: Johannes Berg johannes.b...@intel.com
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
---
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 1 +
drivers/net/wireless/iwlwifi/mvm/sf.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index 9a856e5031f1..c5b086c3f04c 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -971,6 +971,7 @@ static void iwl_mvm_bss_info_changed_station(struct iwl_mvm
*mvm,
*/
iwl_mvm_remove_time_event(mvm, mvmvif,
mvmvif-time_event_data);
+ iwl_mvm_sf_update(mvm, vif, false);
} else if (changes (BSS_CHANGED_PS | BSS_CHANGED_P2P_PS |
BSS_CHANGED_QOS)) {
ret = iwl_mvm_power_update_mode(mvm, vif);
diff --git a/drivers/net/wireless/iwlwifi/mvm/sf.c
b/drivers/net/wireless/iwlwifi/mvm/sf.c
index 8401627c0030..88809b2d1654 100644
--- a/drivers/net/wireless/iwlwifi/mvm/sf.c
+++ b/drivers/net/wireless/iwlwifi/mvm/sf.c
@@ -274,7 +274,8 @@ int iwl_mvm_sf_update(struct iwl_mvm *mvm, struct
ieee80211_vif *changed_vif,
return -EINVAL;
if (changed_vif-type != NL80211_IFTYPE_STATION) {
new_state = SF_UNINIT;
- } else if (changed_vif-bss_conf.assoc) {
+ } else if (changed_vif-bss_conf.assoc
+ changed_vif-bss_conf.dtim_period) {
mvmvif = iwl_mvm_vif_from_mac80211(changed_vif);
sta_id = mvmvif-ap_sta_id;
new_state = SF_FULL_ON;
--
2.0.0.rc0
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.10] mac80211: fix on-channel remain-on-channel
From: Johannes Berg johannes.b...@intel.com
Upstream commit b4b177a5556a686909e643f1e9b6434c10de079f.
Jouni reported that if a remain-on-channel was active on the
same channel as the current operating channel, then the ROC
would start, but any frames transmitted using mgmt-tx on the
same channel would get delayed until after the ROC.
The reason for this is that the ROC starts, but doesn't have
any handling for remain on the same channel, so it stops
the interface queues. The later mgmt-tx then puts the frame
on the interface queues (since it's on the current operating
channel) and thus they get delayed until after the ROC.
To fix this, add some logic to handle remaining on the same
channel specially and not stop the queues etc. in this case.
This not only fixes the bug but also improves behaviour in
this case as data frames etc. can continue to flow.
Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen j...@w1.fi
Tested-by: Jouni Malinen j...@w1.fi
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/offchannel.c | 25 ++---
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 92ef04c72c51..e050acf63c70 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -311,6 +311,7 @@ struct ieee80211_roc_work {
bool started, abort, hw_begun, notified;
bool to_be_freed;
+ bool on_channel;
unsigned long hw_start_time;
diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c
index 11d3f227e11e..0427a58b4397 100644
--- a/net/mac80211/offchannel.c
+++ b/net/mac80211/offchannel.c
@@ -333,7 +333,7 @@ void ieee80211_sw_roc_work(struct work_struct *work)
container_of(work, struct ieee80211_roc_work, work.work);
struct ieee80211_sub_if_data *sdata = roc-sdata;
struct ieee80211_local *local = sdata-local;
- bool started;
+ bool started, on_channel;
mutex_lock(local-mtx);
@@ -354,14 +354,24 @@ void ieee80211_sw_roc_work(struct work_struct *work)
if (!roc-started) {
struct ieee80211_roc_work *dep;
- /* start this ROC */
- ieee80211_offchannel_stop_vifs(local);
+ WARN_ON(local-use_chanctx);
+
+ /* If actually operating on the desired channel (with at least
+* 20 MHz channel width) don't stop all the operations but still
+* treat it as though the ROC operation started properly, so
+* other ROC operations won't interfere with this one.
+*/
+ roc-on_channel = roc-chan == local-_oper_chandef.chan;
- /* switch channel etc */
+ /* start this ROC */
ieee80211_recalc_idle(local);
- local-tmp_channel = roc-chan;
- ieee80211_hw_config(local, 0);
+ if (!roc-on_channel) {
+ ieee80211_offchannel_stop_vifs(local);
+
+ local-tmp_channel = roc-chan;
+ ieee80211_hw_config(local, 0);
+ }
/* tell userspace or send frame */
ieee80211_handle_roc_started(roc);
@@ -380,9 +390,10 @@ void ieee80211_sw_roc_work(struct work_struct *work)
finish:
list_del(roc-list);
started = roc-started;
+ on_channel = roc-on_channel;
ieee80211_roc_notify_destroy(roc, !roc-abort);
- if (started) {
+ if (started !on_channel) {
ieee80211_flush_queues(local, NULL);
local-tmp_channel = NULL;
--
2.0.0.rc0
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: fix suspend vs. association race
On Tue, 2014-05-13 at 12:54 +0300, Emmanuel Grumbach wrote:
If the association is in progress while we suspend, the
stack will be in a messed up state. Clean it before we
suspend.
This patch completes Johannes's patch:
1a1cb744de160ee70086a77afff605bbc275d291
Author: Johannes Berg johannes.b...@intel.com
mac80211: fix suspend vs. authentication race
Cc: stable@vger.kernel.org
Fixes: 12e7f517029d (mac80211: cleanup generic suspend/resume procedures)
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
---
net/mac80211/mlme.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 139005d..5e4f7ea 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3600,7 +3600,7 @@ void ieee80211_mgd_quiesce(struct ieee80211_sub_if_data
*sdata)
sdata_lock(sdata);
- if (ifmgd-auth_data) {
+ if (ifmgd-auth_data || ifmgd-assoc_data) {
This can crash if auth_data is NULL (but we use it to build the deauth)
- I'm rolling in a fix for that.
johannes
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.10.x] mac80211: fix suspend vs. authentication race
From: Johannes Berg johannes.b...@intel.com
Upstream commit 1a1cb744de160ee70086a77afff605bbc275d291, fixed
for cfg80211 API and locking changes.
Since Stanislaw's patch removing the quiescing code, mac80211 had
a race regarding suspend vs. authentication: as cfg80211 doesn't
track authentication attempts, it can't abort them. Therefore the
attempts may be kept running while suspending, which can lead to
all kinds of issues, in at least some cases causing an error in
iwlmvm firmware.
Fix this by aborting the authentication attempt when suspending.
Cc: stable@vger.kernel.org
Fixes: 12e7f517029d (mac80211: cleanup generic suspend/resume procedures)
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/mlme.c| 26 ++
net/mac80211/pm.c | 14 +++---
3 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 92ef04c72c51..ad4a0ca55821 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1270,6 +1270,7 @@ void ieee80211_sta_reset_conn_monitor(struct
ieee80211_sub_if_data *sdata);
void ieee80211_mgd_stop(struct ieee80211_sub_if_data *sdata);
void ieee80211_mgd_conn_tx_status(struct ieee80211_sub_if_data *sdata,
__le16 fc, bool acked);
+void ieee80211_mgd_quiesce(struct ieee80211_sub_if_data *sdata);
void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata);
/* IBSS code */
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 49bc2246bd86..fc94937cd7b3 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3754,6 +3754,32 @@ static void ieee80211_restart_sta_timer(struct
ieee80211_sub_if_data *sdata)
}
#ifdef CONFIG_PM
+void ieee80211_mgd_quiesce(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_if_managed *ifmgd = sdata-u.mgd;
+ u8 frame_buf[IEEE80211_DEAUTH_FRAME_LEN];
+
+ mutex_lock(ifmgd-mtx);
+
+ if (ifmgd-auth_data) {
+ /*
+* If we are trying to authenticate while suspending, cfg80211
+* won't know and won't actually abort those attempts, thus we
+* need to do that ourselves.
+*/
+ ieee80211_send_deauth_disassoc(sdata,
+ ifmgd-auth_data-bss-bssid,
+ IEEE80211_STYPE_DEAUTH,
+ WLAN_REASON_DEAUTH_LEAVING,
+ false, frame_buf);
+ ieee80211_destroy_auth_data(sdata, false);
+ cfg80211_send_deauth(sdata-dev, frame_buf,
+IEEE80211_DEAUTH_FRAME_LEN);
+ }
+
+ mutex_unlock(ifmgd-mtx);
+}
+
void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_if_managed *ifmgd = sdata-u.mgd;
diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
index 340126204343..efb510e6f206 100644
--- a/net/mac80211/pm.c
+++ b/net/mac80211/pm.c
@@ -101,10 +101,18 @@ int __ieee80211_suspend(struct ieee80211_hw *hw, struct
cfg80211_wowlan *wowlan)
/* remove all interfaces that were created in the driver */
list_for_each_entry(sdata, local-interfaces, list) {
- if (!ieee80211_sdata_running(sdata) ||
- sdata-vif.type == NL80211_IFTYPE_AP_VLAN ||
- sdata-vif.type == NL80211_IFTYPE_MONITOR)
+ if (!ieee80211_sdata_running(sdata))
continue;
+ switch (sdata-vif.type) {
+ case NL80211_IFTYPE_AP_VLAN:
+ case NL80211_IFTYPE_MONITOR:
+ continue;
+ case NL80211_IFTYPE_STATION:
+ ieee80211_mgd_quiesce(sdata);
+ break;
+ default:
+ break;
+ }
drv_remove_interface(local, sdata);
}
--
2.0.0.rc0
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: fix WPA with VLAN on AP side with ps-sta again
On Thu, 2014-03-06 at 15:08 +0100, Michael Braun wrote: commit de74a1d9032f4d37ea453ad2a647e1aff4cd2591 mac80211: fix WPA with VLAN on AP side with ps-sta fixed an issue where queued multicast packets would be sent out encrypted with the key of an other bss. commit 7cbf9d017dbb5e3276de7d527925d42d4c11e732 mac80211: fix oops on mesh PS broadcast forwarding essentially reverted it, because vif.type cannot be AP_VLAN due to the check to vif.type in ieee80211_get_buffered_bc before. As the later commit intended to fix the MESH case, fix it by checking for IFTYPE_AP instead of IFTYPE_AP_VLAN. Applied. Fixes: 7cbf9d017dbb I added the commit subject to this. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: check if the ps_buf skb queue hasn't been drained
On Thu, 2014-02-20 at 08:18 +0200, Emmanuel Grumbach wrote: There is a race between the Tx path and the STA wake up flow. If a station is asleep, mac80211 buffers frames, but up to a certain limit. When this limit is reached, mac80211 begins to drop the oldest buffered frames. This is done in the Tx path. When a station wakes up, mac80211 will go over the buffered frames list and send them. Since these two flows can run concurrently, we can get to a situation where the buffered frame list is emptied after the Tx path checked the length of the list. In that case the Tx path would get a NULL skb and crash. I think you should rewrite the commit log - the real fix now isn't really that it can't crash any more, I'd see that as a side effect of the below: This is only a noisy consequence of another bigger issue: since ieee80211_tx_h_unicast_ps_buf is not synced against ieee80211_sta_ps_deliver_wakeup, Tx path could think that the STA is still sleeping and put the packet on the PS skb list while in fact the STA is awake already. In this case, the frame would sit on the PS skb list until the next time the STA wakes up and then, it'd be sent out of order. @@ -486,6 +499,7 @@ ieee80211_tx_h_unicast_ps_buf(struct ieee80211_tx_data *tx) ieee80211_free_txskb(local-hw, old); } else tx-local-total_ps_buffered++; + spin_unlock(sta-lock); That needs to be after adding the frame to the queue. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mac80211: Fix IBSS disconnect
On Thu, 2014-01-30 at 14:17 +0530, Sujith Manoharan wrote: From: Sujith Manoharan c_man...@qca.qualcomm.com Currently, when a station leaves an IBSS network, the corresponding BSS is not dropped from cfg80211 if there are other active stations in the network. But, the small window that is present when trying to determine a station's status based on IEEE80211_IBSS_MERGE_INTERVAL introduces a race. Instead of trying to keep the BSS, always remove it when leaving an IBSS network. There is not much benefit to retain the BSS entry since it will be added with a subsequent join operation. This fixes an issue where a dangling BSS entry causes ath9k to wait for a beacon indefinitely. Applied. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: avoid deadlock revealed by lockdep
On Thu, 2014-01-23 at 14:28 +0200, Emmanuel Grumbach wrote: sdata-u.ap.request_smps_work can’t be flushed synchronously under wdev_lock(wdev) since ieee80211_request_smps_ap_work itself locks the same lock. Applied. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] b43: fix the wrong assignment of status.freq in b43_rx()
On Fri, 2014-01-17 at 23:19 +0800, ZHAO Gang wrote: Use the right function to update status.freq. The wrong frequency value can cause problem that bss info can't be updated when it should be. This bug is introduced by commit 8318d78a44d49ac1edf2bdec7299de3617c4232e cfg80211 API for channels/bitrates, mac80211 and driver conversion. Cc: Stable stable@vger.kernel.org Signed-off-by: ZHAO Gang gamer...@gmail.com --- v3: change commit log suggested by Luca Coelho, Rafał Miłecki and Jonas Gorski I'm not very familiar with wireless subsystem yet. If commit message needs more changes, feel free to point it out. In general, you should also put a Fixes: pseudo-header (with 12-digit commit ID and commit subject) into such commits, so this would be: Cc: stable@vger.kernel.org Fixes: 8318d78a44d4 (cfg80211 API for channels/bitrates, mac80211 and driver conversion) Signed-off-by: ... Thanks for fixing this! johannes -- To unsubscribe from this list: send the line unsubscribe stable 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/3] b43: Fix oops if firmware is not available
On Sun, 2014-01-12 at 04:24 +, Ben Hutchings wrote: You could switch back to synchronous firmware loading soon, as it's not going to support a usermode helper any more. But until then, the proper fix for this is going to be to cancel the waiter earlier in teardown. I don't think we found a way when we looked at this, and instead made the module unload wait for the request_firmware callback to come back (see all users of the request_firmware_complete struct member in iwlwifi/iwl-drv.c) johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.8-3.10] cfg80211: fix scheduled scan pointer access
From: Johannes Berg johannes.b...@intel.com
Upstream commit 79845c662eeb95c9a180b9bd0d3ad848ee65b94c.
Since rdev-sched_scan_req is dereferenced outside the
lock protecting it, this might be done at the wrong
time, causing crashes. Move the dereference to where
it should be - inside the RTNL locked section.
Cc: stable@vger.kernel.org [3.8+]
Reviewed-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/wireless/scan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index fd99ea4..81019ee 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -253,10 +253,10 @@ void __cfg80211_sched_scan_results(struct work_struct *wk)
rdev = container_of(wk, struct cfg80211_registered_device,
sched_scan_results_wk);
- request = rdev-sched_scan_req;
-
mutex_lock(rdev-sched_scan_mtx);
+ request = rdev-sched_scan_req;
+
/* we don't have sched_scan_req anymore if the scan is stopping */
if (request) {
if (request-flags NL80211_SCAN_FLAG_FLUSH) {
--
1.8.4.rc3
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.11-rc6 genetlink locking fix offends lockdep
On Mon, 2013-08-19 at 11:52 -0700, Hugh Dickins wrote:
We could use the semaphore instead, I believe, but I don't really
understand the mutex vs. semaphore well enough to be sure that's
correct.
I don't believe so, the semaphore and cb_mutex don't have a dependency
yet, afaict.
The down_read(cb_lock) patch you suggested gives the lockdep trace below.
Clearly I was wrong then, not sure what I missed in the code though.
From the lockdep trace it looks like the dependency comes via the
genl_lock, I didn't consider that.
David, can you please just revert it for now and tag the revert for
stable as well, in case Greg already took it somewhere? I think that
some stable trees may need a different fix anyway since they don't have
parallel_ops.
We never saw a problem due to this, and though it's probably fairly easy
to trigger by hand-rolling the dump loop in userspace, one does need to
be able to rmmod to crash the kernel with it.
The only way to fix this that I see right now (that doesn't rewrite the
locking completely) would be to make genetlink use parallel_ops itself,
thereby removing the genl_lock() in genl_rcv_msg() and breaking all
those lock chains that lockdep reported. After that, it should be safe
to use genl_lock() inside all the operations. Something like the patch
below, perhaps? Completely untested so far.
johannes
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index f85f8a2..dea9586 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -665,6 +665,7 @@ static struct genl_family genl_ctrl = {
.version = 0x2,
.maxattr = CTRL_ATTR_MAX,
.netnsok = true,
+ .parallel_ops = true,
};
static int ctrl_fill_info(struct genl_family *family, u32 portid, u32 seq,
@@ -789,10 +790,8 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct
netlink_callback *cb)
struct net *net = sock_net(skb-sk);
int chains_to_skip = cb-args[0];
int fams_to_skip = cb-args[1];
- bool need_locking = chains_to_skip || fams_to_skip;
- if (need_locking)
- genl_lock();
+ genl_lock();
for (i = chains_to_skip; i GENL_FAM_TAB_SIZE; i++) {
n = 0;
@@ -814,8 +813,7 @@ errout:
cb-args[0] = i;
cb-args[1] = n;
- if (need_locking)
- genl_unlock();
+ genl_unlock();
return skb-len;
}
@@ -870,6 +868,8 @@ static int ctrl_getfamily(struct sk_buff *skb, struct
genl_info *info)
struct genl_family *res = NULL;
int err = -EINVAL;
+ genl_lock();
+
if (info-attrs[CTRL_ATTR_FAMILY_ID]) {
u16 id = nla_get_u16(info-attrs[CTRL_ATTR_FAMILY_ID]);
res = genl_family_find_byid(id);
@@ -896,19 +896,25 @@ static int ctrl_getfamily(struct sk_buff *skb, struct
genl_info *info)
}
if (res == NULL)
- return err;
+ goto out_unlock;
if (!res-netnsok !net_eq(genl_info_net(info), init_net)) {
/* family doesn't exist here */
- return -ENOENT;
+ err = -ENOENT;
+ goto out_unlock;
}
msg = ctrl_build_family_msg(res, info-snd_portid, info-snd_seq,
CTRL_CMD_NEWFAMILY);
- if (IS_ERR(msg))
- return PTR_ERR(msg);
+ if (IS_ERR(msg)) {
+ err = PTR_ERR(msg);
+ goto out_unlock;
+ }
- return genlmsg_reply(msg, info);
+ err = genlmsg_reply(msg, info);
+out_unlock:
+ genl_unlock();
+ return err;
}
static int genl_ctrl_event(int event, void *data)
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.11-rc6 genetlink locking fix offends lockdep
On Tue, 2013-08-20 at 10:28 +0200, Johannes Berg wrote: The only way to fix this that I see right now (that doesn't rewrite the locking completely) would be to make genetlink use parallel_ops itself, thereby removing the genl_lock() in genl_rcv_msg() and breaking all those lock chains that lockdep reported. After that, it should be safe to use genl_lock() inside all the operations. Something like the patch below, perhaps? Completely untested so far. Tested now, and it still causes lockdep to complain, though that's a lockdep issue I believe, it thinks that genl_mutex and nlk-cb_mutex can be inverted although nlk-cb_mutex exists per family, so we need to annotate lockdep there. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.11-rc6 genetlink locking fix offends lockdep
On Tue, 2013-08-20 at 21:02 +0200, Johannes Berg wrote: On Tue, 2013-08-20 at 10:28 +0200, Johannes Berg wrote: The only way to fix this that I see right now (that doesn't rewrite the locking completely) would be to make genetlink use parallel_ops itself, thereby removing the genl_lock() in genl_rcv_msg() and breaking all those lock chains that lockdep reported. After that, it should be safe to use genl_lock() inside all the operations. Something like the patch below, perhaps? Completely untested so far. Tested now, and it still causes lockdep to complain, though that's a lockdep issue I believe, it thinks that genl_mutex and nlk-cb_mutex can be inverted although nlk-cb_mutex exists per family, so we need to annotate lockdep there. No, lockdep is correct - generic netlink uses the same cb_mutex for all families, obviously, since it's all the same netlink family. I'll just convert it to RCU. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.0.92
[too many email threads, so + a few folks]
This one turns out to be buggy, see thread called 3.11-rc6 genetlink
locking fix offends lockdep.
Yeah, I messed up in keeping it here, I'll go revert it and push out a
new 3.0 release.
Sorry everyone, I thought I tested that code but clearly I didn't test
it well enough. I can easily reproduce the issues now so not sure why I
didn't see it before.
I thought that there was a fix already for this... Ah, no, that was for
another reported regression in an older 3.10-stable release, my bad.
Johannes, what do you want to do here? Just revert it in Linus's tree
for now, given the late -rc cycle?
I think that'd be the best course of action for now. I just tried a few
other approaches but I can't come up with a dead-lock free way to
actually add locking here, short of providing some way for dump to
actually always have locking from outside (netlink code).
I think the better way would be to convert it to just use RCU. This
isn't very efficient, but then again we don't unregister generic netlink
families all the time. Below patch works without lockdep complaining,
but that's obvious since it can't check RCU ... I'm not sure I want to
do this so close to a release?
johannes
From 5b4790a1188c40422e99b4fc8840e4860d57f0d0 Mon Sep 17 00:00:00 2001
From: Johannes Berg johannes.b...@intel.com
Date: Tue, 20 Aug 2013 21:31:48 +0200
Subject: [PATCH] genetlink: convert family dump code to use RCU
In my previous commit 58ad436fcf49810aa006016107f494c9ac9013db
(genetlink: fix family dump race) I attempted to solve an
issue in generic netlink that could lead to crashes, but it
turns out that this introduced a possibility for deadlock. As
I haven't found a way to actually add locking without causing
that, convert the family, family ops/mcast group lists all to
use RCU, so the family dump code can simply use RCU protection
instead of locking.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/netlink/genetlink.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index f85f8a2..ceeaee4 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -246,7 +246,7 @@ static void __genl_unregister_mc_group(struct genl_family
*family,
netlink_table_ungrab();
clear_bit(grp-id, mc_groups);
- list_del(grp-list);
+ list_del_rcu(grp-list);
genl_ctrl_event(CTRL_CMD_DELMCAST_GRP, grp);
grp-id = 0;
grp-family = NULL;
@@ -272,6 +272,7 @@ void genl_unregister_mc_group(struct genl_family *family,
genl_lock_all();
__genl_unregister_mc_group(family, grp);
genl_unlock_all();
+ synchronize_rcu();
}
EXPORT_SYMBOL(genl_unregister_mc_group);
@@ -281,6 +282,7 @@ static void genl_unregister_mc_groups(struct genl_family
*family)
list_for_each_entry_safe(grp, tmp, family-mcast_groups, list)
__genl_unregister_mc_group(family, grp);
+ synchronize_rcu();
}
/**
@@ -351,9 +353,10 @@ int genl_unregister_ops(struct genl_family *family, struct
genl_ops *ops)
genl_lock_all();
list_for_each_entry(rc, family-ops_list, ops_list) {
if (rc == ops) {
- list_del(ops-ops_list);
+ list_del_rcu(ops-ops_list);
genl_unlock_all();
genl_ctrl_event(CTRL_CMD_DELOPS, ops);
+ synchronize_rcu();
return 0;
}
}
@@ -418,7 +421,7 @@ int genl_register_family(struct genl_family *family)
} else
family-attrbuf = NULL;
- list_add_tail(family-family_list, genl_family_chain(family-id));
+ list_add_tail_rcu(family-family_list, genl_family_chain(family-id));
genl_unlock_all();
genl_ctrl_event(CTRL_CMD_NEWFAMILY, family);
@@ -498,7 +501,8 @@ int genl_unregister_family(struct genl_family *family)
if (family-id != rc-id || strcmp(rc-name, family-name))
continue;
- list_del(rc-family_list);
+ list_del_rcu(rc-family_list);
+ synchronize_rcu();
INIT_LIST_HEAD(family-ops_list);
genl_unlock_all();
@@ -692,7 +696,7 @@ static int ctrl_fill_info(struct genl_family *family, u32
portid, u32 seq,
if (nla_ops == NULL)
goto nla_put_failure;
- list_for_each_entry(ops, family-ops_list, ops_list) {
+ list_for_each_entry_rcu(ops, family-ops_list, ops_list) {
struct nlattr *nest;
nest = nla_nest_start(skb, idx++);
@@ -718,7 +722,7 @@ static int ctrl_fill_info(struct genl_family *family, u32
portid, u32 seq,
if (nla_grps == NULL)
goto nla_put_failure;
- list_for_each_entry(grp
Re: Linux 3.0.92
On Tue, 2013-08-20 at 13:00 -0700, Guenter Roeck wrote: Does this patch have to be reverted in 3.10 as well ? Linus' e-mail seems to suggest it, but Shuah didn't see the problem there. I ran a quick test with 3.10.8 on an x86 system and did not see a problem either, at least not immediately. Yes, it does. I'm not sure how hard it is to actually run into the deadlock, though Sergey Senozhatsky said he had seen it. The patch I just posted with the RCU protection actually pretty much reverts my other patch as part of it. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.11-rc6 genetlink locking fix offends lockdep
3.11-rc6's commit 58ad436fcf49 (genetlink: fix family dump race)
gives me the lockdep trace below at startup.
Hmm. Yes, I see now how this happens, not sure why I didn't run into it.
The problem is that genl_family_rcv_msg() is called with the genl_lock
held, and then calls netlink_dump_start() with it held, creating a
genl_lock-cb_mutex dependency, but obviously the dump continuation is
the other way around.
We could use the semaphore instead, I believe, but I don't really
understand the mutex vs. semaphore well enough to be sure that's
correct.
johannes
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index f85f8a2..6cfa646 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -792,7 +792,7 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct
netlink_callback *cb)
bool need_locking = chains_to_skip || fams_to_skip;
if (need_locking)
- genl_lock();
+ down_read(cb_lock);
for (i = chains_to_skip; i GENL_FAM_TAB_SIZE; i++) {
n = 0;
@@ -815,7 +815,7 @@ errout:
cb-args[1] = n;
if (need_locking)
- genl_unlock();
+ up_read(cb_lock);
return skb-len;
}
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.11-rc6 genetlink locking fix offends lockdep
On Mon, 2013-08-19 at 19:00 +0800, Ding Tianhong wrote: On 2013/8/19 16:00, Johannes Berg wrote: 3.11-rc6's commit 58ad436fcf49 (genetlink: fix family dump race) gives me the lockdep trace below at startup. Hmm. Yes, I see now how this happens, not sure why I didn't run into it. The problem is that genl_family_rcv_msg() is called with the genl_lock held, and then calls netlink_dump_start() with it held, creating a genl_lock-cb_mutex dependency, but obviously the dump continuation is the other way around. We could use the semaphore instead, I believe, but I don't really understand the mutex vs. semaphore well enough to be sure that's correct. johannes it is useless, the logic need to modify or otherwise it will still call lockdep trace. I don't believe so, the semaphore and cb_mutex don't have a dependency yet, afaict. maybe i could send a patch for it, if you wish. What do you mean? johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3.11] genetlink: fix family dump race
On Sun, 2013-08-11 at 21:29 -0700, David Miller wrote:
BUG: unable to handle kernel paging request at f8467360
IP: [c14c56bb] ctrl_dumpfamily+0x6b/0xe0
EIP: 0060:[c14c56bb] EFLAGS: 00210297 CPU: 2
EIP is at ctrl_dumpfamily+0x6b/0xe0
EAX: f8467378 EBX: f8467340 ECX: EDX: ec1610c4
ESI: 0001 EDI: c2077cc0 EBP: c46c3c00 ESP: c46c3bd4
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 80050033 CR2: f8467360 CR3: 26e54000 CR4: 001407d0
DR0: DR1: DR2: DR3:
DR6: 0ff0 DR7: 0400
Process wpa_supplicant (pid: 20081, ti=c46c2000 task=c44640b0
task.ti=c46c2000)
Call Trace:
[c14c20bc] netlink_dump+0x5c/0x200
[c14c3450] __netlink_dump_start+0x140/0x160
[c14c5172] genl_rcv_msg+0x102/0x270
[c14c4b5e] netlink_rcv_skb+0x8e/0xb0
[c14c505c] genl_rcv+0x1c/0x30
[c14c456b] netlink_unicast+0x17b/0x1c0
[c14c47d4] netlink_sendmsg+0x224/0x370
[c1485adf] sock_sendmsg+0xff/0x120
I completely agree with your analysis that we need locking here, but
the crash OOPS backtrace doesn't make any sense to me.
The bug should trigger when we enter the dump continuation path, which
would look like:
ctrl_dumpfamily()
netlink_dump()
netlink_recvmsg()
...
Since this is the only way we get into ctrl_dumpfamily() without
holding genl_lock().
But in your trace we're going through genl_rcv() which means this is
the first call of the dump, and genl_rcv() takes the necessary locks.
Huh, yes, I only looked at the crash info as far as I needed to see that
it was crashing at accessing rt-netnsok with a not totally invalid
pointer rt (it's in EBX) and then went from the code ...
Ok, I see what's going on here. The bug was reported to me against an
old kernel (3.4.47!) and that actually did an unlock in genl_rcv_msg()
before calling netlink_dump_start():
if (nlh-nlmsg_flags NLM_F_DUMP) {
if (ops-dumpit == NULL)
return -EOPNOTSUPP;
genl_unlock();
{
struct netlink_dump_control c = {
.dump = ops-dumpit,
.done = ops-done,
};
err = netlink_dump_start(net-genl_sock, skb,
nlh, c);
}
genl_lock();
return err;
}
That was changed in Pravin's commit
def3117493eafd9dfa1f809d861e0031b2cc8a07
genl: Allow concurrent genl callbacks. very recently - I'm not sure if
that was intentional, it's not described in the commit log.
I think for the current code the fix would still be correct, I can
change the commit message if you like. For backporting, we'll have to
check which tree has Pravin's change and which doesn't and change this
accordingly, I suppose.
johannes
--
To unsubscribe from this list: send the line unsubscribe stable 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.10 0/3] Enable 7000 device family on 3.10
[Emmanuel is on vacation, I'll cover for him] On Fri, 2013-08-02 at 17:02 +0800, Greg KH wrote: On Mon, Jul 15, 2013 at 02:44:57PM +0300, Emmanuel Grumbach wrote: This small patch series enables 7260 and 3160 devices on 3.10 kernel. Three patches are already in linux.git (3.11-rc1). One patch is 3.10 specific and disables configuration that is not supported in 3.10. I need the git commit id of these patches in Linus's tree before I can apply them. Please resend them with that information. The second and third patch does have it, and the first patch is only relevant for 3.10 since 3.11 will have more device types enabled, we just didn't get all the code in. This seems to be described in the commit log, do you want more details? johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3.10] iwlwifi: mvm: set SSID bits for passive channels
From: David Spinadel david.spina...@intel.com
Upstream commit bb963c4a43eb5127eb0bbfa16c7a6a209b0af5db.
Set SSID bitmap for direct scan even on passive channels,
for the passive-to-active feature. Without this patch only
the SSID from probe request template is sent on passive
channels, after passive-to-active switching, causing us to
not find all desired networks.
Remove the unused passive scan mask constant.
Cc: stable@vger.kernel.org
Reviewed-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: David Spinadel david.spina...@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h | 1 -
drivers/net/wireless/iwlwifi/mvm/scan.c| 11 ++-
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h
b/drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h
index b60d141..365095a 100644
--- a/drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h
+++ b/drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h
@@ -69,7 +69,6 @@
/* Scan Commands, Responses, Notifications */
/* Masks for iwl_scan_channel.type flags */
-#define SCAN_CHANNEL_TYPE_PASSIVE 0
#define SCAN_CHANNEL_TYPE_ACTIVE BIT(0)
#define SCAN_CHANNEL_NARROW_BAND BIT(22)
diff --git a/drivers/net/wireless/iwlwifi/mvm/scan.c
b/drivers/net/wireless/iwlwifi/mvm/scan.c
index 2476e43..c53a63b 100644
--- a/drivers/net/wireless/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/iwlwifi/mvm/scan.c
@@ -176,19 +176,12 @@ static void iwl_mvm_scan_fill_channels(struct
iwl_scan_cmd *cmd,
struct iwl_scan_channel *chan = (struct iwl_scan_channel *)
(cmd-data + le16_to_cpu(cmd-tx_cmd.len));
int i;
- __le32 chan_type_value;
-
- if (req-n_ssids 0)
- chan_type_value = cpu_to_le32(BIT(req-n_ssids + 1) - 1);
- else
- chan_type_value = SCAN_CHANNEL_TYPE_PASSIVE;
for (i = 0; i cmd-channel_count; i++) {
chan-channel = cpu_to_le16(req-channels[i]-hw_value);
+ chan-type = cpu_to_le32(BIT(req-n_ssids) - 1);
if (req-channels[i]-flags IEEE80211_CHAN_PASSIVE_SCAN)
- chan-type = SCAN_CHANNEL_TYPE_PASSIVE;
- else
- chan-type = chan_type_value;
+ chan-type = cpu_to_le32(~SCAN_CHANNEL_TYPE_ACTIVE);
chan-active_dwell = cpu_to_le16(active_dwell);
chan-passive_dwell = cpu_to_le16(passive_dwell);
chan-iteration_count = cpu_to_le16(1);
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3.10] iwlwifi: dvm: don't send BT_CONFIG on devices w/o Bluetooth
From: Johannes Berg johannes.b...@intel.com
Upstream commit 707aee401d2467baa785a697f40a6e2d9ee79ad5.
The BT_CONFIG command that is sent to the device during
startup will enable BT coex unless the module parameter
turns it off, but on devices without Bluetooth this may
cause problems, as reported in Redhat BZ 885407.
Fix this by sending the BT_CONFIG command only when the
device has Bluetooth.
Cc: stable@vger.kernel.org
Reviewed-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: Johannes Berg johan...@sipsolutions.net
---
drivers/net/wireless/iwlwifi/dvm/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlwifi/dvm/main.c
b/drivers/net/wireless/iwlwifi/dvm/main.c
index 74d7572..a8afc7b 100644
--- a/drivers/net/wireless/iwlwifi/dvm/main.c
+++ b/drivers/net/wireless/iwlwifi/dvm/main.c
@@ -758,7 +758,7 @@ int iwl_alive_start(struct iwl_priv *priv)
BT_COEX_PRIO_TBL_EVT_INIT_CALIB2);
if (ret)
return ret;
- } else {
+ } else if (priv-cfg-bt_params) {
/*
* default is 2-wire BT coexexistence support
*/
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.9] mac80211: work around broken APs not including HT info
From: Johannes Berg johannes.b...@intel.com
Upstream commit 35d865afbbdf79e492f7d61df92b1a9e1d93d26f.
There are some APs, notably 2G/3G/4G Wifi routers, specifically the
Onda PN51T, Vodafone PocketWiFi 2, ZTE MF60 and a similar
T-Mobile branded device [1] that erroneously don't include all the
needed information in (re)association response frames. Work around
this by assuming the information is the same as it was in the
beacon or probe response and using the data from there instead.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=58881.
[1] https://bbs.archlinux.org/viewtopic.php?pid=1277305
Note that this requires marking the first ieee802_11_parse_elems()
argument const, otherwise we'd get a compiler warning.
Cc: stable@vger.kernel.org
Reported-and-tested-by: Michal Zajac ma...@manwe.pl
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/ieee80211_i.h | 4 +--
net/mac80211/mlme.c| 87 ++
net/mac80211/util.c| 6 ++--
3 files changed, 85 insertions(+), 12 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 5672533..4e74cd6 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1520,9 +1520,9 @@ static inline void ieee80211_tx_skb(struct
ieee80211_sub_if_data *sdata,
ieee80211_tx_skb_tid(sdata, skb, 7);
}
-void ieee802_11_parse_elems(u8 *start, size_t len,
+void ieee802_11_parse_elems(const u8 *start, size_t len,
struct ieee802_11_elems *elems);
-u32 ieee802_11_parse_elems_crc(u8 *start, size_t len,
+u32 ieee802_11_parse_elems_crc(const u8 *start, size_t len,
struct ieee802_11_elems *elems,
u64 filter, u32 crc);
u32 ieee80211_mandatory_rates(struct ieee80211_local *local,
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0a60f40..9726603 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2422,8 +2422,11 @@ static bool ieee80211_assoc_success(struct
ieee80211_sub_if_data *sdata,
u16 capab_info, aid;
struct ieee802_11_elems elems;
struct ieee80211_bss_conf *bss_conf = sdata-vif.bss_conf;
+ const struct cfg80211_bss_ies *bss_ies = NULL;
+ struct ieee80211_mgd_assoc_data *assoc_data = ifmgd-assoc_data;
u32 changed = 0;
int err;
+ bool ret;
/* AssocResp and ReassocResp have identical structure */
@@ -2455,21 +2458,86 @@ static bool ieee80211_assoc_success(struct
ieee80211_sub_if_data *sdata,
ifmgd-aid = aid;
/*
+* Some APs are erroneously not including some information in their
+* (re)association response frames. Try to recover by using the data
+* from the beacon or probe response. This seems to afflict mobile
+* 2G/3G/4G wifi routers, reported models include the Onda PN51T,
+* Vodafone PocketWiFi 2, ZTE MF60 and a similar T-Mobile device.
+*/
+ if ((assoc_data-wmm !elems.wmm_param) ||
+ (!(ifmgd-flags IEEE80211_STA_DISABLE_HT)
+(!elems.ht_cap_elem || !elems.ht_operation)) ||
+ (!(ifmgd-flags IEEE80211_STA_DISABLE_VHT)
+(!elems.vht_cap_elem || !elems.vht_operation))) {
+ const struct cfg80211_bss_ies *ies;
+ struct ieee802_11_elems bss_elems;
+
+ rcu_read_lock();
+ ies = rcu_dereference(cbss-ies);
+ if (ies)
+ bss_ies = kmemdup(ies, sizeof(*ies) + ies-len,
+ GFP_ATOMIC);
+ rcu_read_unlock();
+ if (!bss_ies)
+ return false;
+
+ ieee802_11_parse_elems(bss_ies-data, bss_ies-len,
+ bss_elems);
+ if (assoc_data-wmm
+ !elems.wmm_param bss_elems.wmm_param) {
+ elems.wmm_param = bss_elems.wmm_param;
+ sdata_info(sdata,
+ AP bug: WMM param missing from
AssocResp\n);
+ }
+
+ /*
+* Also check if we requested HT/VHT, otherwise the AP doesn't
+* have to include the IEs in the (re)association response.
+*/
+ if (!elems.ht_cap_elem bss_elems.ht_cap_elem
+ !(ifmgd-flags IEEE80211_STA_DISABLE_HT)) {
+ elems.ht_cap_elem = bss_elems.ht_cap_elem;
+ sdata_info(sdata,
+ AP bug: HT capability missing from
AssocResp\n);
+ }
+ if (!elems.ht_operation bss_elems.ht_operation
+ !(ifmgd-flags IEEE80211_STA_DISABLE_HT)) {
+ elems.ht_operation = bss_elems.ht_operation;
+ sdata_info(sdata,
+ AP bug: HT operation missing from
[PATCH 3.6-3.9] mac80211_hwsim: remove P2P_DEVICE support
From: Johannes Berg johannes.b...@intel.com
Unfortunately, advertising P2P_DEVICE support was a little
premature, a number of issues came up in testing and have
been fixed for 3.10. Rather than try to backport all the
different fixes, disable P2P_DEVICE support in the drivers
using it.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
drivers/net/wireless/mac80211_hwsim.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index cb34c78..69bbf6f 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2169,7 +2169,6 @@ static const struct ieee80211_iface_limit
hwsim_if_limits[] = {
#endif
BIT(NL80211_IFTYPE_AP) |
BIT(NL80211_IFTYPE_P2P_GO) },
- { .max = 1, .types = BIT(NL80211_IFTYPE_P2P_DEVICE) },
};
static struct ieee80211_iface_combination hwsim_if_comb = {
@@ -2295,8 +2294,7 @@ static int __init init_mac80211_hwsim(void)
BIT(NL80211_IFTYPE_P2P_CLIENT) |
BIT(NL80211_IFTYPE_P2P_GO) |
BIT(NL80211_IFTYPE_ADHOC) |
- BIT(NL80211_IFTYPE_MESH_POINT) |
- BIT(NL80211_IFTYPE_P2P_DEVICE);
+ BIT(NL80211_IFTYPE_MESH_POINT);
hw-flags = IEEE80211_HW_MFP_CAPABLE |
IEEE80211_HW_SIGNAL_DBM |
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.9] iwlwifi: mvm: remove P2P_DEVICE support
From: Johannes Berg johannes.b...@intel.com
Unfortunately, advertising P2P_DEVICE support was a little
premature, a number of issues came up in testing and have
been fixed for 3.10. Rather than try to backport all the
different fixes, disable P2P_DEVICE support in the drivers
using it. For iwlmvm that implies disabling P2P completely
as it can't support P2P operation w/o P2P Device.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index dd158ec..11dc7df 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -84,15 +84,6 @@ static const struct ieee80211_iface_limit iwl_mvm_limits[] =
{
.types = BIT(NL80211_IFTYPE_STATION) |
BIT(NL80211_IFTYPE_AP),
},
- {
- .max = 1,
- .types = BIT(NL80211_IFTYPE_P2P_CLIENT) |
- BIT(NL80211_IFTYPE_P2P_GO),
- },
- {
- .max = 1,
- .types = BIT(NL80211_IFTYPE_P2P_DEVICE),
- },
};
static const struct ieee80211_iface_combination iwl_mvm_iface_combinations[] =
{
@@ -161,10 +152,7 @@ int iwl_mvm_mac_setup_register(struct iwl_mvm *mvm)
hw-chanctx_data_size = sizeof(struct iwl_mvm_phy_ctxt);
hw-wiphy-interface_modes = BIT(NL80211_IFTYPE_STATION) |
- BIT(NL80211_IFTYPE_P2P_CLIENT) |
- BIT(NL80211_IFTYPE_AP) |
- BIT(NL80211_IFTYPE_P2P_GO) |
- BIT(NL80211_IFTYPE_P2P_DEVICE);
+ BIT(NL80211_IFTYPE_AP);
hw-wiphy-flags |= WIPHY_FLAG_CUSTOM_REGULATORY |
WIPHY_FLAG_DISABLE_BEACON_HINTS |
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mysterious (?) VHT/HT warning on 3.8.2
On Sat, 2013-03-30 at 18:49 -0700, Andrew Lutomirski wrote: wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded Despite this warning, HT seems to work. I'm getting 7 MB/s over ssh, which isn't terrible. Yeah, the warning is spurious, it's disabling VHT because neither you nor the AP have it ;-) I fixed it in commit 586e01ededf9b713a1512dd658806791a7ca1a50 Author: Johannes Berg johannes.b...@intel.com Date: Thu Feb 14 12:13:53 2013 +0100 mac80211: prevent spurious HT/VHT downgrade message but I guess that didn't make it to 3.8, maybe it should be applied to stable. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression: tethering fails in 3.5 with iwlwifi
On Mon, 2012-09-17 at 17:41 +0300, Artem Bityutskiy wrote: OK, finally I got it. After 3 days of hardcore intelligent bisecting I've found out that tethering in 3.5 works for me if I revert these 2 patches: 56138f5 iwlwifi: dont pull too much payload in skb head I got back to this for a customer running 3.5, and after many failed attempts realized that you have to have iptables for this problem to actually happen. I reverse-bisected that the *fix* is 6caab7b0544e83e6c160b5e80f5a4a7dd69545c7, in 3.7. Is there still any stable kernel 3.5/3.6 (or possibly before, though for iwlwifi before doesn't matter) that this should be applied to? johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.8] mac80211: prevent spurious HT/VHT downgrade message
From: Johannes Berg johannes.b...@intel.com
Commit 586e01ededf9b713a1512dd658806791a7ca1a50 upstream.
Even when connecting to an AP that doesn't support VHT,
and even when the local device doesn't support it either,
the downgrade message gets printed. Suppress the message
if HT and/or VHT is disabled.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/mlme.c | 4
1 file changed, 4 insertions(+)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 5107248..55a7fdd 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3401,6 +3401,10 @@ ieee80211_determine_chantype(struct
ieee80211_sub_if_data *sdata,
ret = 0;
out:
+ /* don't print the message below for VHT mismatch if VHT is disabled */
+ if (ret IEEE80211_STA_DISABLE_VHT)
+ vht_chandef = *chandef;
+
while (!cfg80211_chandef_usable(sdata-local-hw.wiphy, chandef,
IEEE80211_CHAN_DISABLED)) {
if (WARN_ON(chandef-width == NL80211_CHAN_WIDTH_20_NOHT)) {
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.8] mac80211: always unblock CSA queue stop when disconnecting
From: Johannes Berg johannes.b...@intel.com Commit 5b36ebd8249f403c7edf7cf68d68e9a0d0f55243 upstream. In some cases when disconnecting after (or during?) CSA the queues might not recover, and then the only way to recover is reloading the module. Fix this by always unblocking the queue CSA reason when disconnecting. Cc: stable@vger.kernel.org Reported-by: Jan-Michael Brummer jan.brum...@tabos.org Signed-off-by: Johannes Berg johannes.b...@intel.com --- net/mac80211/mlme.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 5107248..f75ba1a 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -1812,6 +1812,8 @@ static void __ieee80211_disconnect(struct ieee80211_sub_if_data *sdata, WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY, transmit_frame, frame_buf); ifmgd-flags = ~IEEE80211_STA_CSA_RECEIVED; + ieee80211_wake_queues_by_reason(sdata-local-hw, + IEEE80211_QUEUE_STOP_REASON_CSA); mutex_unlock(ifmgd-mtx); /* @@ -1856,8 +1858,6 @@ static void ieee80211_csa_connection_drop_work(struct work_struct *work) container_of(work, struct ieee80211_sub_if_data, u.mgd.csa_connection_drop_work); - ieee80211_wake_queues_by_reason(sdata-local-hw, - IEEE80211_QUEUE_STOP_REASON_CSA); __ieee80211_disconnect(sdata, true); } -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtlwifi: rtl8192cu: Fix NULL dereference BUG when using new_id
On Wed, 2013-02-06 at 01:16 +, Ben Hutchings wrote: I don't know why USB differs from PCI, but we do need the dynamic ID here as there are always new IDs being issued. One of the criteria for adding the ID to the table is that it works OK with dynamic addition. These devices are frequently reported by users that do not have the skills to build their own kernel. But since there is no way to set the driver_info for a new USB ID (again, unlike PCI), your change will reject all dynamic IDs. (And in any case, if the USB core were changed to allow setting driver_info, userland would have difficulty providing a valid pointer!) It looks like the driver_info is really driver-specific data used to share a probe function between multiple drivers. But you could add per-driver probe functions that pass the correct rtl_hal_cfg as an extra argument to rtl_usb_probe(), and then dynamic IDs should work. Some (PCI?) drivers had/have numbers instead of pointers, so userland can provide a number and it then looks up the pointer in an array. That's only slightly indirected but makes new_id more useful in that case. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mac80211: fix memory leak in device registration error path
On Mon, 2012-11-26 at 12:06 -0700, Shuah Khan wrote: Greg/Johannes, I was looking at git-commits-head archive and comparing it to stable commits and found the following patch might have missed getting into stable. I see a few other mac80211 fixes that got pulled in, but not this one. Something that just got missed getting into stable? http://marc.info/?l=git-commits-headm=135311368602856w=2 Gitweb: http://git.kernel.org/linus/;a=commit;h=cfff2f999d9baa561f20d999c8b83b03f078fb8f Commit: cfff2f999d9baa561f20d999c8b83b03f078fb8f Parent: 987c285c2ae2e4e32aca3a9b3252d28171c75711 Author: Johannes Berg johannes.b...@intel.com AuthorDate: Fri Nov 9 09:47:27 2012 +0100 Committer: Johannes Berg johannes.b...@intel.com CommitDate: Fri Nov 9 09:48:43 2012 +0100 mac80211: fix memory leak in device registration error path Looks like this patch was posted to linux-wireless.vger.kernel.org originally. Reference: https://patchwork.kernel.org/patch/1719641/ Applies cleanly to stable latest 3.6.x, 3.4.x and 3.0.x. Should this be pulled into these trees? *shrug* I've never once seen a report of this function failing (other than with developers getting things wrong during development) so I didn't tag it with Cc stable. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.6.5
Hi Eddie, The AP is a Netgear WNR2000v3 running DD-WRT v24-sp2 (03/19/12) std. After sshing into it and playing around with the iw command, the phy is phy0 and the device is ath0. iw ath0 scan dump returns nothing unfortunately. Yeah, sorry, I guess I confused you. I did want this info from the client, as you provided: In case it helps, on the laptop (the client) I do get output from iw wlan0 scan dump: BSS 82:e1:fa:1a:65:00 (on wlan0) -- associated [...] HT operation: * primary channel: 9 * secondary channel offset: above As you can see, it's using HT40+ on channel 9 (2452 MHz). Your HT40 allow (correctly) map showed: 2452 HT40 - This is because HT40+ isn't actually allowed on channel 9 by the standard (cf. 802.11-2012 Table E-1 (US), E-2 (Europe), E-3 (Japan). I wonder, what is the oldest kernel you tried? I think the fact that we can connect here was introduced by some older patch, and then reverted by my patch, so older kernels should have been slower as well? The problem here is that some devices (notably iwlwifi) will not allow (by firmware) to connect to such an AP as HT40- if that is not allowed. So I prevented it generally, but we can make it device dependent. I don't like it much, but I suppose we can do it. Try this patch: http://p.sipsolutions.net/0129f39c7d882289.txt It will still prohibit this configuration when the driver said it's not allowed, but will allow it when there were other reasons to not allow it. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.6.5
On Tue, 2012-11-06 at 16:54 +0100, Johannes Berg wrote: BSS 82:e1:fa:1a:65:00 (on wlan0) -- associated [...] HT operation: * primary channel: 9 * secondary channel offset: above As you can see, it's using HT40+ on channel 9 (2452 MHz). Your HT40 allow (correctly) map showed: 2452 HT40 - This is because HT40+ isn't actually allowed on channel 9 by the standard (cf. 802.11-2012 Table E-1 (US), E-2 (Europe), E-3 (Japan). Oops, no, that is obviously wrong. This is permitted outside the US, and that is reflected in those tables as well (I was confused). However, your AP isn't transmitting any info on where it is, and your device is set up for world roaming (country is 00 rather than a real country). Thus, channel 13 isn't allowed and you can't do HT40+ on channel 9. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.6.5
On Tue, 2012-11-06 at 17:39 +0100, Johannes Berg wrote: On Tue, 2012-11-06 at 16:54 +0100, Johannes Berg wrote: BSS 82:e1:fa:1a:65:00 (on wlan0) -- associated [...] HT operation: * primary channel: 9 * secondary channel offset: above As you can see, it's using HT40+ on channel 9 (2452 MHz). Your HT40 allow (correctly) map showed: 2452 HT40 - This is because HT40+ isn't actually allowed on channel 9 by the standard (cf. 802.11-2012 Table E-1 (US), E-2 (Europe), E-3 (Japan). Oops, no, that is obviously wrong. This is permitted outside the US, and that is reflected in those tables as well (I was confused). However, your AP isn't transmitting any info on where it is, and your device is set up for world roaming (country is 00 rather than a real country). Thus, channel 13 isn't allowed and you can't do HT40+ on channel 9. Here's another idea. I'm not sure if you're running CRDA, but you could try this patch: http://p.sipsolutions.net/8877cbe3440d94b1.txt and see if iw reg get changes like this: country 00: (2402 - 2472 @ 40), (6, 20) -(2457 - 2482 @ 20), (6, 20), PASSIVE-SCAN, NO-IBSS +(2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS (5170 - 5250 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS (5735 - 5835 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS (57240 - 63720 @ 2160), (N/A, 0) If yes, then your problem will likely go away, if no you'd need an updated regulatory database for CRDA. +Luis, what do you think? johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.6.5
Hi Eddie, In the AP's dmesg output which I included in my other message, I see this: 6[9.30] cfg80211: Regulatory domain changed to country: GB So it seems the AP knows where it is, but is it not transmitting that to the client? Evidently, I don't see a country IE in the iw scan output you posted. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.6.5
On Tue, 2012-11-06 at 17:55 +0100, Johannes Berg wrote: Hi Eddie, In the AP's dmesg output which I included in my other message, I see this: 6[9.30] cfg80211: Regulatory domain changed to country: GB So it seems the AP knows where it is, but is it not transmitting that to the client? Evidently, I don't see a country IE in the iw scan output you posted. Then again, what version of iw do you have? This only applies if it's version 0.9.20 or higher. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.6.5
On Tue, 2012-11-06 at 18:59 +, Eddie Chapman wrote: On 06/11/12 15:54, Johannes Berg wrote: The problem here is that some devices (notably iwlwifi) will not allow (by firmware) to connect to such an AP as HT40- if that is not allowed. So I prevented it generally, but we can make it device dependent. I don't like it much, but I suppose we can do it. Try this patch: http://p.sipsolutions.net/0129f39c7d882289.txt It will still prohibit this configuration when the driver said it's not allowed, but will allow it when there were other reasons to not allow it. Just to report, with the patch under discussion re-applied (3a40414f826a8f1096d9b94c4a53ef91b25ba28d), plus the patch at your link above, my throughput is back to normal again. Ok, thanks. So I guess the above patch resolves the issue (on the face of it) for me, but whether it is a suitable solution I've no idea. Right, we're still looking at that. It seems that it's not an ideal solution, the regulatory change I proposed is probably better. Could you check if it helps as well? That is, remove this patch, and apply this one: http://p.sipsolutions.net/8877cbe3440d94b1.txt johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.6.5
On Tue, 2012-11-06 at 19:35 +, Eddie Chapman wrote: Right, we're still looking at that. It seems that it's not an ideal solution, the regulatory change I proposed is probably better. Could you check if it helps as well? That is, remove this patch, and apply this one: http://p.sipsolutions.net/8877cbe3440d94b1.txt OK, so I've removed 0129f39c7d882289.txt, applied 8877cbe3440d94b1.txt, and I've kept 3a40414f826a8f1096d9b94c4a53ef91b25ba28d applied. Rebooted, and happy to report throughput is still good, so 8877cbe3440d94b1.txt also fixes it for me. Great, thanks. I'm not really sure which one to apply, and if we apply the 8877 one we'll also want to update the reg db (that you aren't using). A lot of people are in Barcelona right now though, so that might be a week or so until we can close this. Thanks for all the testing! johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.6.5
On Wed, 2012-11-07 at 08:36 +0100, Greg KH wrote: Great, thanks. I'm not really sure which one to apply, and if we apply the 8877 one we'll also want to update the reg db (that you aren't using). A lot of people are in Barcelona right now though, so that might be a week or so until we can close this. I'm in Barcelona all this week, but a nice summary of what I'm supposed to do here for the stable tree would be great to have when ever you figure it out, don't wait for me to return, my email queues up just fine :) Sure :) So first of all, I'm sure (even without Eddie having tested it) that the bug affects 3.7-rc as well, not just 3.6 stable, since the same patch was applied there. Therefore, we're looking for a fix for that as well. There are two possible fixes (that I can think of right now), both of which Eddie tested. One is a change to my old change, to make it only adhere to the regulatory rules that the *driver* asked for, which will still fix the iwlwifi problem of crashing the firmware in situations like Eddie's. However, it's a bit strange to be ignoring our regulatory rules. The other fix is a relaxation of the regulatory rules to allow 40 MHz operation involving channels 12 and 13 (like in Eddie's setup, where channel 9 HT40+ is used, which means the effective channel spans from the bottom of channel 6 to the top of channel 13.) This seems like a much cleaner solution, but the change needs to be done in two places (both the kernel's idea of the world roaming regulatory domain, and userspace's). I prefer the second fix, but want to run it by somebody more familiar with regulatory rules. Ultimately, I'll apply either one for 3.7, and tag it with Cc stable. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.6.5
On Mon, 2012-11-05 at 11:04 +, Eddie Chapman wrote: And, can you also test 3.7-rc4, to ensure that the problem isn't there as well? I've narrowed it down to this patch which introduces the problem: Johannes Berg: mac80211: connect with HT20 if HT40 is not permitted commit: 3a40414f826a8f1096d9b94c4a53ef91b25ba28d The other 3 patches above give me no problems at all, so I am now running my 3.6.5 with those 3 back in, and just the HT20/HT40 patch removed, and throughput is perfect. As soon as I introduce the patch HT20/HT40 throughput drops right down to a fifth of what it was. This should also be the case on 3.7-rc4, since the patch came from there, and I don't see any reason to believe rt2800 would behave differently here, for some reason. Can you show me the contents of the /sys/kernel/debug/ieee80211/phy0/ht40allow_map debugfs file and iw reg get command? johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: sync acccess to tx_filtered/ps_tx_buf queues
On Mon, 2012-11-05 at 10:27 +0200, Arik Nemtsov wrote: These are accessed without a lock when ending STA PSM. If the sta_cleanup timer accesses these lists at the same time, we might crash. This may fix some mysterious crashes we had during ieee80211_sta_ps_deliver_wakeup. Cc: stable@vger.kernel.org Signed-off-by: Arik Nemtsov a...@wizery.com Signed-off-by: Ido Yariv i...@wizery.com Applied, thanks! johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.6.5
Hi Eddie, Here is the output of /sys/kernel/debug/ieee80211/phy0/ht40allow_map: Ok, thanks. 2412 HT40 + 2417 HT40 + 2422 HT40 + 2427 HT40 + 2432 HT40 -+ 2437 HT40 -+ 2442 HT40 -+ 2447 HT40 - 2452 HT40 - 2457 HT40 - 2462 HT40 - 2467 HT40 2472 HT40 2484 HT40 That looks correct. and iw reg get says: country 00: (2402 - 2472 @ 40), (6, 20) (2457 - 2482 @ 20), (6, 20), PASSIVE-SCAN, NO-IBSS (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS (5170 - 5250 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS (5735 - 5835 @ 40), (6, 20), PASSIVE-SCAN, NO-IBSS (57240 - 63720 @ 2160), (N/A, 0) That also looks fine. I captured both of these with the HT20/HT40 patch applied. Ok, that shouldn't change anything in this case, but good to know. let me know if you need anything else. Yeah, I forgot to ask about the AP. Can you show the output of iw wlan0 scan dump for your AP while you're connected? It should show something like this (note the associated indication): BSS 02:00:00:00:00:00 (on wlan1) -- associated TSF: 1352188517669470 usec (15650d, 07:55:17) freq: 2432 [...] I'm particularly interested in the freq (as above) and the HT capabilities/operation information. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3.5] iwlwifi: don't double free the interrupt in failure path
From: Emmanuel Grumbach emmanuel.grumb...@intel.com Upstream commit a7be50b7e30f9d77cb059a7ffdb781bb0fb92eba. When the driver can't get the HW ready, we would release the interrupt twice which made the kernel complain loudly. Cc: stable@vger.kernel.org Reported-by: Brian Cockrell brian.cockr...@intel.com Tested-by: Brian Cockrell brian.cockr...@intel.com Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com Signed-off-by: Johannes Berg johannes.b...@intel.com Signed-off-by: John W. Linville linvi...@tuxdriver.com --- drivers/net/wireless/iwlwifi/iwl-trans-pcie.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c +++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c @@ -1437,6 +1437,7 @@ static int iwl_trans_pcie_start_hw(struct iwl_trans *trans) return err; err_free_irq: + trans_pcie-irq_requested = false; free_irq(trans_pcie-irq, trans); error: iwl_free_isr_ict(trans); -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3.5 1/2] iwlwifi: protect SRAM debugfs
From: Johannes Berg johannes.b...@intel.com
Upstream commit 4fc79db178f0a0ede479b4713e00df2d106028b3.
If the device is not started, we can't read its
SRAM and attempting to do so will cause issues.
Protect the debugfs read.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg johannes.b...@intel.com
Signed-off-by: John W. Linville linvi...@tuxdriver.com
---
drivers/net/wireless/iwlwifi/iwl-debugfs.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/iwlwifi/iwl-debugfs.c
b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
index 7f97dec..5000690 100644
--- a/drivers/net/wireless/iwlwifi/iwl-debugfs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
@@ -128,6 +128,9 @@ static ssize_t iwl_dbgfs_sram_read(struct file *file,
const struct fw_img *img;
size_t bufsz;
+ if (!iwl_is_ready_rf(priv))
+ return -EAGAIN;
+
/* default is to dump the entire data segment */
if (!priv-dbgfs_sram_offset !priv-dbgfs_sram_len) {
priv-dbgfs_sram_offset = 0x80;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3.5 2/2] iwlwifi: fix flow handler debug code
From: Johannes Berg johannes.b...@intel.com
Upstream commit 94543a8d4fb302817014981489f15cb3b92ec3c2.
iwl_dbgfs_fh_reg_read() can cause crashes and/or
BUG_ON in slub because the ifdefs are wrong, the
code in iwl_dump_fh() should use DEBUGFS, not
DEBUG to protect the buffer writing code.
Also, while at it, clean up the arguments to the
function, some code and make it generally safer.
Cc: stable@vger.kernel.org
Reported-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Johannes Berg johannes.b...@intel.com
Signed-off-by: John W. Linville linvi...@tuxdriver.com
---
drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h |2 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c |2 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c | 30 +++--
3 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
index e959207..8215fad 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
@@ -355,7 +355,7 @@ int iwl_queue_space(const struct iwl_queue *q);
/*
* Error handling
**/
-int iwl_dump_fh(struct iwl_trans *trans, char **buf, bool display);
+int iwl_dump_fh(struct iwl_trans *trans, char **buf);
void iwl_dump_csr(struct iwl_trans *trans);
/*
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
index 08517d3..5e18ff9 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
@@ -559,7 +559,7 @@ static void iwl_irq_handle_error(struct iwl_trans *trans)
}
iwl_dump_csr(trans);
- iwl_dump_fh(trans, NULL, false);
+ iwl_dump_fh(trans, NULL);
iwl_op_mode_nic_error(trans-op_mode);
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
b/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
index 79c6b91..0a68170 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
@@ -1654,13 +1654,9 @@ static const char *get_fh_string(int cmd)
#undef IWL_CMD
}
-int iwl_dump_fh(struct iwl_trans *trans, char **buf, bool display)
+int iwl_dump_fh(struct iwl_trans *trans, char **buf)
{
int i;
-#ifdef CONFIG_IWLWIFI_DEBUG
- int pos = 0;
- size_t bufsz = 0;
-#endif
static const u32 fh_tbl[] = {
FH_RSCSR_CHNL0_STTS_WPTR_REG,
FH_RSCSR_CHNL0_RBDCB_BASE_REG,
@@ -1672,29 +1668,35 @@ int iwl_dump_fh(struct iwl_trans *trans, char **buf,
bool display)
FH_TSSR_TX_STATUS_REG,
FH_TSSR_TX_ERROR_REG
};
-#ifdef CONFIG_IWLWIFI_DEBUG
- if (display) {
- bufsz = ARRAY_SIZE(fh_tbl) * 48 + 40;
+
+#ifdef CONFIG_IWLWIFI_DEBUGFS
+ if (buf) {
+ int pos = 0;
+ size_t bufsz = ARRAY_SIZE(fh_tbl) * 48 + 40;
+
*buf = kmalloc(bufsz, GFP_KERNEL);
if (!*buf)
return -ENOMEM;
+
pos += scnprintf(*buf + pos, bufsz - pos,
FH register values:\n);
- for (i = 0; i ARRAY_SIZE(fh_tbl); i++) {
+
+ for (i = 0; i ARRAY_SIZE(fh_tbl); i++)
pos += scnprintf(*buf + pos, bufsz - pos,
%34s: 0X%08x\n,
get_fh_string(fh_tbl[i]),
iwl_read_direct32(trans, fh_tbl[i]));
- }
+
return pos;
}
#endif
+
IWL_ERR(trans, FH register values:\n);
- for (i = 0; i ARRAY_SIZE(fh_tbl); i++) {
+ for (i = 0; i ARRAY_SIZE(fh_tbl); i++)
IWL_ERR(trans, %34s: 0X%08x\n,
get_fh_string(fh_tbl[i]),
iwl_read_direct32(trans, fh_tbl[i]));
- }
+
return 0;
}
@@ -1989,11 +1991,11 @@ static ssize_t iwl_dbgfs_fh_reg_read(struct file *file,
size_t count, loff_t *ppos)
{
struct iwl_trans *trans = file-private_data;
- char *buf;
+ char *buf = NULL;
int pos = 0;
ssize_t ret = -EFAULT;
- ret = pos = iwl_dump_fh(trans, buf, true);
+ ret = pos = iwl_dump_fh(trans, buf);
if (buf) {
ret = simple_read_from_buffer(user_buf,
count, ppos, buf, pos);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.5] iwlwifi: Check BSS ctx active before call mac80211
From: Ilan Peer ilan.p...@intel.com
Upstream commit e19ebcab01cc130fa832764d453b263460ec3b91.
It is possible that the BSS context is not active (for example
when the current mode is set to GO), or that the vif-type is
different than station. In such a case we cannot
call mac80211 to report the average rssi for the interface
(the function assumes that the vif is valid and that the type
is station).
Reviewed-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: Ilan Peer ilan.p...@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
This patch narrowly missed 3.5 but is needed there to fix a crash, see
e.g. https://bugzilla.kernel.org/show_bug.cgi?id=45481
drivers/net/wireless/iwlwifi/iwl-agn-lib.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index e55ec6c..c31072d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -617,6 +617,11 @@ static bool iwlagn_fill_txpower_mode(struct iwl_priv *priv,
struct iwl_rxon_context *ctx = priv-contexts[IWL_RXON_CTX_BSS];
int ave_rssi;
+ if (!ctx-vif || (ctx-vif-type != NL80211_IFTYPE_STATION)) {
+ IWL_DEBUG_INFO(priv, BSS ctx not active or not in sta mode\n);
+ return false;
+ }
+
ave_rssi = ieee80211_ave_rssi(ctx-vif);
if (!ave_rssi) {
/* no rssi data, no changes to reduce tx power */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] Fix inability to configure adhoc in 3.4.x
On Wed, 2012-08-01 at 12:14 -0400, Paul Gortmaker wrote: [...] However, things still weren't right unless he also cherry picked the 8e8b41f9d8c8e6 (cfg80211: enforce lack of interface combinations) to get the later mentioned total == 1 check within, so that we avoid the EBUSY above. But this commit causes other regressions (as described in the commit log of the attached patch) so we didn't think it best to go that route for 3.4.x. So, the options we considered (to fix 3.4.x stable) were: 1) cherry pick 8e8b41f9d, and all the driver specific changes it requires 2) make a sub-commit for stable that just takes the total==1 from #1. 3) patch iwlwifi/iwl-mac80211.c and add .types = BIT(NL80211_IFTYPE_ADHOC) 4) treat ADHOC as a universal feature that everyone has. The following patch does #4, and in theory it could be used in mainline and then cherry picked back to stable. But we weren't 100% sure if that was the best solution, since neither of us are really wireless people, hence all the detail here. Thanks for the detailed analysis. Given 8e8b41f9d, I don't think any mainline changes are actually needed? I don't think #4 is right, not all drivers do in fact support IBSS. Making them advertise it will just cause issues. I think #2 would be the best option. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] Fix inability to configure adhoc in 3.4.x
On Wed, 2012-08-01 at 13:38 -0400, Paul Gortmaker wrote: 1) cherry pick 8e8b41f9d, and all the driver specific changes it requires 2) make a sub-commit for stable that just takes the total==1 from #1. 3) patch iwlwifi/iwl-mac80211.c and add .types = BIT(NL80211_IFTYPE_ADHOC) 4) treat ADHOC as a universal feature that everyone has. The following patch does #4, and in theory it could be used in mainline and then cherry picked back to stable. But we weren't 100% sure if that was the best solution, since neither of us are really wireless people, hence all the detail here. Thanks for the detailed analysis. Given 8e8b41f9d, I don't think any mainline changes are actually needed? Perhaps not. I know Liang was looking at the ath5k and ath9k changes: 9b4760e ath5k: add possible wiphy interface combinations 20c8e8d ath9k: add possible wiphy interface combinations and thinking that the above commits plus the total==1 change wouldn't fix any ATH multifunction cards (if they exist) in the ad-hoc use case - but we didn't have such hardware to test with. I'm not sure what you mean by wouldn't fix here -- the way the devices advertise their multi-virtual-interface support is that they do not support IBSS (ad-hoc) in combination with any other interface. Therefore, pure IBSS should be covered by the total==1 case? johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.5] iwlwifi: Check BSS ctx active before call mac80211
From: Ilan Peer ilan.p...@intel.com
Upstream commit e19ebcab01cc130fa832764d453b263460ec3b91. I
had erroneously thought this didn't apply to 3.5 but Daniel
ran into the error there.
It is possible that the BSS context is not active (for example
when the current mode is set to GO), or that the vif-type is
different than station. In such a case we cannot
call mac80211 to report the average rssi for the interface
(the function assumes that the vif is valid and that the type
is station).
Reported-by: Daniel J Blueman dan...@quora.org
Reviewed-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: Ilan Peer ilan.p...@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
drivers/net/wireless/iwlwifi/iwl-agn-lib.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index e55ec6c..c31072d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -617,6 +617,11 @@ static bool iwlagn_fill_txpower_mode(struct iwl_priv *priv,
struct iwl_rxon_context *ctx = priv-contexts[IWL_RXON_CTX_BSS];
int ave_rssi;
+ if (!ctx-vif || (ctx-vif-type != NL80211_IFTYPE_STATION)) {
+ IWL_DEBUG_INFO(priv, BSS ctx not active or not in sta mode\n);
+ return false;
+ }
+
ave_rssi = ieee80211_ave_rssi(ctx-vif);
if (!ave_rssi) {
/* no rssi data, no changes to reduce tx power */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.4] mac80211: fix queues stuck issue with HT bandwidth change
From: Johannes Berg johannes.b...@intel.com No upstream commit, the buggy code was removed in 3.5. Rajkumar changed code for handling channel switching in mac80211 to stop the queues in commit 7cc44ed48d0ec0937c1f098642540b6c9ca38de5 Author: Rajkumar Manoharan rmano...@qca.qualcomm.com Date: Fri Sep 16 15:32:34 2011 +0530 mac80211: Fix regression on queue stop during 2040 bss change which went into 3.2. In the 3.4 cycle, Paul's change commit 3117bbdb7899d43927c8ce4fe885ab7c1231c121 Author: Paul Stewart ps...@chromium.org Date: Tue Mar 13 07:46:18 2012 -0700 mac80211: Don't let regulatory make us deaf went in and changed the TX/RX enable logic, but now the conditions for stopping and restarting the queues were different so that now, if the AP changes between 20/40 MHz bandwidth, it can happen that we stop but never restart the queues. This breaks the connection and the module actually has to be reloaded to get it back to work. Fix this by making sure the queues are always started when they were stopped. Reported-by: Florian Manschwetus manschwe...@googlemail.com Signed-off-by: Johannes Berg johannes.b...@intel.com --- net/mac80211/mlme.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 20c680b..025a844 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -187,7 +187,7 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata, u32 changed = 0; int hti_cfreq; u16 ht_opmode; - bool enable_ht = true; + bool enable_ht = true, queues_stopped = false; enum nl80211_channel_type prev_chantype; enum nl80211_channel_type rx_channel_type = NL80211_CHAN_NO_HT; enum nl80211_channel_type tx_channel_type; @@ -254,6 +254,7 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata, */ ieee80211_stop_queues_by_reason(sdata-local-hw, IEEE80211_QUEUE_STOP_REASON_CHTYPE_CHANGE); + queues_stopped = true; /* flush out all packets */ synchronize_net(); @@ -272,12 +273,12 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata, IEEE80211_RC_HT_CHANGED, tx_channel_type); rcu_read_unlock(); - - if (beacon_htcap_ie) - ieee80211_wake_queues_by_reason(sdata-local-hw, - IEEE80211_QUEUE_STOP_REASON_CHTYPE_CHANGE); } + if (queues_stopped) + ieee80211_wake_queues_by_reason(sdata-local-hw, + IEEE80211_QUEUE_STOP_REASON_CHTYPE_CHANGE); + ht_opmode = le16_to_cpu(hti-operation_mode); /* if bss configuration changed store the new one */ -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe stable 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] mac80211: fix queues stuck issue with HT bandwidth change
On Wed, 2012-06-27 at 15:32 -0500, Jonathan Nieder wrote: Johannes Berg wrote: No upstream commit, the buggy code was removed in 3.5. What upstream commit removed the buggy code? Nothing git can't answer :-) 7213cf2cb0dfbb4d6b55a1da000d34338f76c0e3 But of course that just removed the queue stop. Really, the buggy bits with channel_type vs. rx_channel_type/tx_channel_type were removed in 24398e39c8ee4a9d9123eed322b859ece4d16cac because that commit changed the logic around the stop/wake queue. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.4] iwlwifi: fix the Transmit Frame Descriptor rings
From: Emmanuel Grumbach emmanuel.grumb...@intel.com
commit ebed633c61c023e5d1aa4ed159cd67406e9e37c2 upstream.
The logic that allows to have a short TFD queue was completely wrong.
We do maintain 256 Transmit Frame Descriptors, but they point to
recycled buffers. We used to attach and de-attach different TFDs for
the same buffer and it worked since they pointed to the same buffer.
Also zero the number of BDs after unmapping a TFD. This seems not
necessary since we don't reclaim the same TFD twice, but I like
housekeeping.
This patch solves this warning:
[ 6427.079855] WARNING: at lib/dma-debug.c:866 check_unmap+0x727/0x7a0()
[ 6427.079859] Hardware name: Latitude E6410
[ 6427.079865] iwlwifi :02:00.0: DMA-API: device driver tries to free DMA
memory it has not allocated [device address=0x296d393c] [size=8 bytes]
[ 6427.079870] Modules linked in: ...
[ 6427.079950] Pid: 6613, comm: ifconfig Tainted: G O 3.3.3 #5
[ 6427.079954] Call Trace:
[ 6427.079963] [c10337a2] warn_slowpath_common+0x72/0xa0
[ 6427.079982] [c1033873] warn_slowpath_fmt+0x33/0x40
[ 6427.079988] [c12dcb77] check_unmap+0x727/0x7a0
[ 6427.079995] [c12dcdaa] debug_dma_unmap_page+0x5a/0x80
[ 6427.080024] [fe2312ac] iwlagn_unmap_tfd+0x12c/0x180 [iwlwifi]
[ 6427.080048] [fe231349] iwlagn_txq_free_tfd+0x49/0xb0 [iwlwifi]
[ 6427.080071] [fe228e37] iwl_tx_queue_unmap+0x67/0x90 [iwlwifi]
[ 6427.080095] [fe22d221] iwl_trans_pcie_stop_device+0x341/0x7b0 [iwlwifi]
[ 6427.080113] [fe204b0e] iwl_down+0x17e/0x260 [iwlwifi]
[ 6427.080132] [fe20efec] iwlagn_mac_stop+0x6c/0xf0 [iwlwifi]
[ 6427.080168] [fd8480ce] ieee80211_stop_device+0x5e/0x190 [mac80211]
[ 6427.080198] [fd833208] ieee80211_do_stop+0x288/0x620 [mac80211]
[ 6427.080243] [fd8335b7] ieee80211_stop+0x17/0x20 [mac80211]
[ 6427.080250] [c148dac1] __dev_close_many+0x81/0xd0
[ 6427.080270] [c148db3d] __dev_close+0x2d/0x50
[ 6427.080276] [c148d152] __dev_change_flags+0x82/0x150
[ 6427.080282] [c148e3e3] dev_change_flags+0x23/0x60
[ 6427.080289] [c14f6320] devinet_ioctl+0x6a0/0x770
[ 6427.080296] [c14f8705] inet_ioctl+0x95/0xb0
[ 6427.080304] [c147a0f0] sock_ioctl+0x70/0x270
Cc: stable@vger.kernel.org
Reported-by: Antonio Quartulli or...@autistici.org
Tested-by: Antonio Quartulli or...@autistici.org
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h |2 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c | 20 +---
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c |4 +---
3 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
index 1c2fe87..3b844b7 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
@@ -342,7 +342,7 @@ void iwl_trans_pcie_tx_agg_setup(struct iwl_trans *trans,
enum iwl_rxon_context_id ctx,
int sta_id, int tid, int frame_limit, u16 ssn);
void iwlagn_txq_free_tfd(struct iwl_trans *trans, struct iwl_tx_queue *txq,
- int index, enum dma_data_direction dma_dir);
+enum dma_data_direction dma_dir);
int iwl_tx_queue_reclaim(struct iwl_trans *trans, int txq_id, int index,
struct sk_buff_head *skbs);
int iwl_queue_space(const struct iwl_queue *q);
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
index e92972f..d7964b1 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
@@ -237,32 +237,38 @@ static void iwlagn_unmap_tfd(struct iwl_trans *trans,
struct iwl_cmd_meta *meta,
for (i = 1; i num_tbs; i++)
dma_unmap_single(trans-dev, iwl_tfd_tb_get_addr(tfd, i),
iwl_tfd_tb_get_len(tfd, i), dma_dir);
+
+ tfd-num_tbs = 0;
}
/**
* iwlagn_txq_free_tfd - Free all chunks referenced by TFD [txq-q.read_ptr]
* @trans - transport private data
* @txq - tx queue
- * @index - the index of the TFD to be freed
- *@dma_dir - the direction of the DMA mapping
+ * @dma_dir - the direction of the DMA mapping
*
* Does NOT advance any TFD circular buffer read/write indexes
* Does NOT free the TFD itself (which is within circular buffer)
*/
void iwlagn_txq_free_tfd(struct iwl_trans *trans, struct iwl_tx_queue *txq,
- int index, enum dma_data_direction dma_dir)
+enum dma_data_direction dma_dir)
{
struct iwl_tfd *tfd_tmp = txq-tfds;
+ /* rd_ptr is bounded by n_bd and idx is bounded by n_window */
+ int rd_ptr = txq-q.read_ptr;
+ int idx = get_cmd_index(txq-q, rd_ptr);
+
lockdep_assert_held(txq-lock);
- iwlagn_unmap_tfd(trans, txq-meta[index], tfd_tmp[index
[PATCH 3.4] iwlwifi: use correct supported firmware for 6035 and 6000g2
From: Meenakshi Venkataraman meenakshi.venkatara...@intel.com
commit d2c8b15d0cb486f4938ba7f2af349d9d1220cb10 upstream.
My patch
iwlwifi: use correct released ucode version
did not correctly report supported firmware
for the 6035 device. This patch fixes it. The
minimum supported firmware version for 6035
is v6.
Also correct the minimum supported firmware
version for the 6000g2 series of devices.
Cc: sta...@kernel.org
Signed-off-by: Meenakshi Venkataraman meenakshi.venkatara...@intel.com
Reviewed-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
drivers/net/wireless/iwlwifi/iwl-6000.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-6000.c
b/drivers/net/wireless/iwlwifi/iwl-6000.c
index 9f71b85..c0cfa4e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-6000.c
@@ -49,17 +49,20 @@
#define IWL6000_UCODE_API_MAX 6
#define IWL6050_UCODE_API_MAX 5
#define IWL6000G2_UCODE_API_MAX 6
+#define IWL6035_UCODE_API_MAX 6
/* Oldest version we won't warn about */
#define IWL6000_UCODE_API_OK 4
#define IWL6000G2_UCODE_API_OK 5
#define IWL6050_UCODE_API_OK 5
#define IWL6000G2B_UCODE_API_OK 6
+#define IWL6035_UCODE_API_OK 6
/* Lowest firmware API version supported */
#define IWL6000_UCODE_API_MIN 4
#define IWL6050_UCODE_API_MIN 4
-#define IWL6000G2_UCODE_API_MIN 4
+#define IWL6000G2_UCODE_API_MIN 5
+#define IWL6035_UCODE_API_MIN 6
#define IWL6000_FW_PRE iwlwifi-6000-
#define IWL6000_MODULE_FIRMWARE(api) IWL6000_FW_PRE __stringify(api) .ucode
@@ -425,9 +428,25 @@ const struct iwl_cfg iwl6030_2bg_cfg = {
IWL_DEVICE_6030,
};
+#define IWL_DEVICE_6035\
+ .fw_name_pre = IWL6030_FW_PRE, \
+ .ucode_api_max = IWL6035_UCODE_API_MAX, \
+ .ucode_api_ok = IWL6035_UCODE_API_OK, \
+ .ucode_api_min = IWL6035_UCODE_API_MIN, \
+ .max_inst_size = IWL60_RTC_INST_SIZE, \
+ .max_data_size = IWL60_RTC_DATA_SIZE, \
+ .eeprom_ver = EEPROM_6030_EEPROM_VERSION, \
+ .eeprom_calib_ver = EEPROM_6030_TX_POWER_VERSION, \
+ .lib = iwl6030_lib,\
+ .base_params = iwl6000_g2_base_params, \
+ .bt_params = iwl6000_bt_params,\
+ .need_temp_offset_calib = true, \
+ .led_mode = IWL_LED_RF_STATE, \
+ .adv_pm = true
+
const struct iwl_cfg iwl6035_2agn_cfg = {
.name = Intel(R) Centrino(R) Advanced-N 6235 AGN,
- IWL_DEVICE_6030,
+ IWL_DEVICE_6035,
.ht_params = iwl6000_ht_params,
};
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.4] iwlwifi: fix TX power antenna access
From: Johannes Berg johannes.b...@intel.com
commit a5fdde28b4f5fb756032e7ad2c6fcdcffde20958 upstream.
Since my commit
iwlwifi: use valid TX/RX antenna from hw_params
the config values are pure overrides, not the
real values for all hardware. Therefore, the
EEPROM TX power reading code checks the wrong
values, it should check the hw_params values.
Cc: sta...@kernel.org [3.4]
Reviewed-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom.c
b/drivers/net/wireless/iwlwifi/iwl-eeprom.c
index 23cea42..79dddc4 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.c
@@ -513,28 +513,28 @@ static int iwl_find_otp_image(struct iwl_trans *trans,
* iwl_get_max_txpower_avg - get the highest tx power from all chains.
* find the highest tx power from all chains for the channel
*/
-static s8 iwl_get_max_txpower_avg(const struct iwl_cfg *cfg,
+static s8 iwl_get_max_txpower_avg(struct iwl_priv *priv,
struct iwl_eeprom_enhanced_txpwr *enhanced_txpower,
int element, s8 *max_txpower_in_half_dbm)
{
s8 max_txpower_avg = 0; /* (dBm) */
/* Take the highest tx power from any valid chains */
- if ((cfg-valid_tx_ant ANT_A)
+ if ((hw_params(priv).valid_tx_ant ANT_A)
(enhanced_txpower[element].chain_a_max max_txpower_avg))
max_txpower_avg = enhanced_txpower[element].chain_a_max;
- if ((cfg-valid_tx_ant ANT_B)
+ if ((hw_params(priv).valid_tx_ant ANT_B)
(enhanced_txpower[element].chain_b_max max_txpower_avg))
max_txpower_avg = enhanced_txpower[element].chain_b_max;
- if ((cfg-valid_tx_ant ANT_C)
+ if ((hw_params(priv).valid_tx_ant ANT_C)
(enhanced_txpower[element].chain_c_max max_txpower_avg))
max_txpower_avg = enhanced_txpower[element].chain_c_max;
- if (((cfg-valid_tx_ant == ANT_AB) |
- (cfg-valid_tx_ant == ANT_BC) |
- (cfg-valid_tx_ant == ANT_AC))
+ if (((hw_params(priv).valid_tx_ant == ANT_AB) |
+ (hw_params(priv).valid_tx_ant == ANT_BC) |
+ (hw_params(priv).valid_tx_ant == ANT_AC))
(enhanced_txpower[element].mimo2_max max_txpower_avg))
max_txpower_avg = enhanced_txpower[element].mimo2_max;
- if ((cfg-valid_tx_ant == ANT_ABC)
+ if ((hw_params(priv).valid_tx_ant == ANT_ABC)
(enhanced_txpower[element].mimo3_max max_txpower_avg))
max_txpower_avg = enhanced_txpower[element].mimo3_max;
@@ -637,7 +637,7 @@ static void iwl_eeprom_enhanced_txpower(struct iwl_priv
*priv)
((txp-delta_20_in_40 0xf0) 4),
(txp-delta_20_in_40 0x0f));
- max_txp_avg = iwl_get_max_txpower_avg(cfg(priv), txp_array, idx,
+ max_txp_avg = iwl_get_max_txpower_avg(priv, txp_array, idx,
max_txp_avg_halfdbm);
/*
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: fix non RCU-safe sta_list manipulation
On Sun, 2012-06-03 at 23:32 +0300, Arik Nemtsov wrote: sta_info_cleanup locks the sta_list using rcu_read_lock however the delete operation isn't rcu safe. A race between sta_info_cleanup timer being called and a STA being removed can occur which leads to a panic while traversing sta_list. Fix this by switching to the RCU-safe versions. Good catch! johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath9k: Fix a WARNING in suspend/resume with IBSS
Hi Mohammed,
You could just remove the entire check since the interface combinations
you advertise don't allow it, I think? Or just fix those
combinations :-)
i did not check this before, thanks a lot for your inputs. will send a
proper v2 after checking this out.
If this is needed for stable, you might want to keep this patch send
another one to remove it.
thanks Johannes.
i was looking at how to fix this properly in iface combination
advertised to mac80211. got few doubts regarding this
*if an interface type is not all advertised in the
ieee80211_iface_combination then it cannot it be co-existing with any
other interfaces ?
please let me know is there some other way do that.
if we advertise something like this
static const struct ieee80211_iface_limit if_limits[] = {
{set1
},
{set 2
},
};
then interface types in set1 and set2 co-exist as per the logic in
cfg80211_can_change_interface. is there already a way we can make
set1 and set2 interface types mutually exclusive ? thanks!
The sets are mutually exclusive, and there are implied sets of each
interface with a max number of 1. So for example, in iwlwifi we don't
advertise IBSS in the combinations at all, because it's not compatible
with anything. In your case, I think the same applies, since you said
if the first interface is ADHOC we cannot have any other
interface. we cannot add an ADHOC interface if there is already
an interface is present
Thus, if you leave IBSS out of the combinations you should get the
desired behaviour of not being able to combine IBSS with any other
types.
johannes
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath9k: Fix a WARNING in suspend/resume with IBSS
On Fri, 2012-06-01 at 12:39 +0530, Mohammed Shafi Shajakhan wrote:
Hi Johannes,
On Friday 01 June 2012 12:14 PM, Johannes Berg wrote:
On Fri, 2012-06-01 at 12:09 +0530, Mohammed Shafi Shajakhan wrote:
From: Mohammed Shafi Shajakhanmoham...@qca.qualcomm.com
In ath9k we make sure the following two things
*if the first interface is ADHOC we cannot have any other interface.
*we cannot add an ADHOC interface if there is already an interface
is present.
- if ((ah-opmode == NL80211_IFTYPE_ADHOC) ||
- ((vif-type == NL80211_IFTYPE_ADHOC)
- sc-nvifs 0)) {
- ath_err(common, Cannot create ADHOC interface when other
- interfaces already exist.\n);
+ if ((ah-opmode == NL80211_IFTYPE_ADHOC) (sc-nvifs 0)) {
+ ath_err(common, Cannot create any other interface when an
ADHOC interface already exists.\n);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if ((vif-type == NL80211_IFTYPE_ADHOC) (sc-nvifs 0)) {
+ ath_err(common, Cannot create ADHOC interface when other
interfaces already exist.\n);
You could just remove the entire check since the interface combinations
you advertise don't allow it, I think? Or just fix those
combinations :-)
i did not check this before, thanks a lot for your inputs. will send a
proper v2 after checking this out.
If this is needed for stable, you might want to keep this patch send
another one to remove it.
johannes
--
To unsubscribe from this list: send the line unsubscribe stable 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/4] iwlwifi: fix the Transmit Frame Descriptor rings
John, The logic that allows to have a short TFD queue was completely wrong. We do maintain 256 Transmit Frame Descriptors, but they point to recycled buffers. We used to attach and de-attach different TFDs for the same buffer and it worked since they pointed to the same buffer. Also zero the number of BDs after unmapping a TFD. This seems not necessary since we don't reclaim the same TFD twice, but I like housekeeping. Cc: stable@vger.kernel.org This is Cc stable, can we also get it to 3.4 still? If not I guess Greg will pick it up johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] iwlwifi: fix the Transmit Frame Descriptor rings
From: Emmanuel Grumbach emmanuel.grumb...@intel.com
The logic that allows to have a short TFD queue was completely wrong.
We do maintain 256 Transmit Frame Descriptors, but they point to
recycled buffers. We used to attach and de-attach different TFDs for
the same buffer and it worked since they pointed to the same buffer.
Also zero the number of BDs after unmapping a TFD. This seems not
necessary since we don't reclaim the same TFD twice, but I like
housekeeping.
This patch solves this warning:
[ 6427.079855] WARNING: at lib/dma-debug.c:866 check_unmap+0x727/0x7a0()
[ 6427.079859] Hardware name: Latitude E6410
[ 6427.079865] iwlwifi :02:00.0: DMA-API: device driver tries to free DMA
memory it has not allocated [device address=0x296d393c] [size=8 bytes]
[ 6427.079870] Modules linked in: ...
[ 6427.079950] Pid: 6613, comm: ifconfig Tainted: G O 3.3.3 #5
[ 6427.079954] Call Trace:
[ 6427.079963] [c10337a2] warn_slowpath_common+0x72/0xa0
[ 6427.079982] [c1033873] warn_slowpath_fmt+0x33/0x40
[ 6427.079988] [c12dcb77] check_unmap+0x727/0x7a0
[ 6427.079995] [c12dcdaa] debug_dma_unmap_page+0x5a/0x80
[ 6427.080024] [fe2312ac] iwlagn_unmap_tfd+0x12c/0x180 [iwlwifi]
[ 6427.080048] [fe231349] iwlagn_txq_free_tfd+0x49/0xb0 [iwlwifi]
[ 6427.080071] [fe228e37] iwl_tx_queue_unmap+0x67/0x90 [iwlwifi]
[ 6427.080095] [fe22d221] iwl_trans_pcie_stop_device+0x341/0x7b0 [iwlwifi]
[ 6427.080113] [fe204b0e] iwl_down+0x17e/0x260 [iwlwifi]
[ 6427.080132] [fe20efec] iwlagn_mac_stop+0x6c/0xf0 [iwlwifi]
[ 6427.080168] [fd8480ce] ieee80211_stop_device+0x5e/0x190 [mac80211]
[ 6427.080198] [fd833208] ieee80211_do_stop+0x288/0x620 [mac80211]
[ 6427.080243] [fd8335b7] ieee80211_stop+0x17/0x20 [mac80211]
[ 6427.080250] [c148dac1] __dev_close_many+0x81/0xd0
[ 6427.080270] [c148db3d] __dev_close+0x2d/0x50
[ 6427.080276] [c148d152] __dev_change_flags+0x82/0x150
[ 6427.080282] [c148e3e3] dev_change_flags+0x23/0x60
[ 6427.080289] [c14f6320] devinet_ioctl+0x6a0/0x770
[ 6427.080296] [c14f8705] inet_ioctl+0x95/0xb0
[ 6427.080304] [c147a0f0] sock_ioctl+0x70/0x270
Cc: stable@vger.kernel.org
Reported-by: Antonio Quartulli or...@autistici.org
Tested-by: Antonio Quartulli or...@autistici.org
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Reviewed-by: Wey-Yi W Guy wey-yi.w@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h |2 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c | 22 +
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c |4 +---
3 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
index 6213c05..e959207 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
@@ -347,7 +347,7 @@ void iwl_trans_tx_queue_set_status(struct iwl_trans *trans,
void iwl_trans_pcie_tx_agg_setup(struct iwl_trans *trans, int queue, int fifo,
int sta_id, int tid, int frame_limit, u16 ssn);
void iwlagn_txq_free_tfd(struct iwl_trans *trans, struct iwl_tx_queue *txq,
- int index, enum dma_data_direction dma_dir);
+enum dma_data_direction dma_dir);
int iwl_tx_queue_reclaim(struct iwl_trans *trans, int txq_id, int index,
struct sk_buff_head *skbs);
int iwl_queue_space(const struct iwl_queue *q);
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
index 21a8a67..a875023 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
@@ -204,33 +204,39 @@ static void iwlagn_unmap_tfd(struct iwl_trans *trans,
struct iwl_cmd_meta *meta,
for (i = 1; i num_tbs; i++)
dma_unmap_single(trans-dev, iwl_tfd_tb_get_addr(tfd, i),
iwl_tfd_tb_get_len(tfd, i), dma_dir);
+
+ tfd-num_tbs = 0;
}
/**
* iwlagn_txq_free_tfd - Free all chunks referenced by TFD [txq-q.read_ptr]
* @trans - transport private data
* @txq - tx queue
- * @index - the index of the TFD to be freed
- *@dma_dir - the direction of the DMA mapping
+ * @dma_dir - the direction of the DMA mapping
*
* Does NOT advance any TFD circular buffer read/write indexes
* Does NOT free the TFD itself (which is within circular buffer)
*/
void iwlagn_txq_free_tfd(struct iwl_trans *trans, struct iwl_tx_queue *txq,
- int index, enum dma_data_direction dma_dir)
+enum dma_data_direction dma_dir)
{
struct iwl_tfd *tfd_tmp = txq-tfds;
+ /* rd_ptr is bounded by n_bd and idx is bounded by n_window */
+ int rd_ptr = txq-q.read_ptr;
+ int idx = get_cmd_index(txq-q, rd_ptr);
+
lockdep_assert_held(txq-lock);
- iwlagn_unmap_tfd(trans, txq-entries[index].meta
Re: [RFC] mac80211: Fix a rwlock bad magic bug
On 2/9/2012 2:04 PM, Mohammed Shafi Shajakhan wrote: From: Mohammed Shafi Shajakhanmoham...@qca.qualcomm.com read_lock(tpt_trig-trig.leddev_list_lock) is accessed via the path ieee80211_open (-) ieee80211_do_open (-) ieee80211_mod_tpt_led_trig (-) ieee80211_start_tpt_led_trig (-) tpt_trig_timer before initializing it. the intilization of this read/write lock happens via the path ieee80211_led_init (-) led_trigger_register, but we are doing 'ieee80211_led_init' after 'i80211_if_add' where we register netdev_ops. so we access leddev_list_lock before initializing it and causes the following bug in chrome laptops with AR928X cards with the following script while true do sudo modprobe -v ath9k sleep 3 sudo modprobe -r ath9k sleep 3 done BUG: rwlock bad magic on CPU#1, wpa_supplicant/358, f5b9eccc Pid: 358, comm: wpa_supplicant Not tainted 3.0.13 #1 Call Trace: [8137b9df] rwlock_bug+0x3d/0x47 [81179830] do_raw_read_lock+0x19/0x29 [8137f063] _raw_read_lock+0xd/0xf [f9081957] tpt_trig_timer+0xc3/0x145 [mac80211] [f9081f3a] ieee80211_mod_tpt_led_trig+0x152/0x174 [mac80211] [f9076a3f] ieee80211_do_open+0x11e/0x42e [mac80211] [f9075390] ? ieee80211_check_concurrent_iface+0x26/0x13c [mac80211] [f9076d97] ieee80211_open+0x48/0x4c [mac80211] [812dbed8] __dev_open+0x82/0xab [812dc0c9] __dev_change_flags+0x9c/0x113 [812dc1ae] dev_change_flags+0x18/0x44 [8132144f] devinet_ioctl+0x243/0x51a [81321ba9] inet_ioctl+0x93/0xac [812cc951] sock_ioctl+0x1c6/0x1ea [812cc78b] ? might_fault+0x20/0x20 [810b1ebb] do_vfs_ioctl+0x46e/0x4a2 [810a6ebb] ? fget_light+0x2f/0x70 [812ce549] ? sys_recvmsg+0x3e/0x48 [810b1f35] sys_ioctl+0x46/0x69 [8137fa77] sysenter_do_call+0x12/0x2 Cc:stable@vger.kernel.org Cc: Gary Moraingmor...@google.com Cc: Paul Stewartps...@google.com Cc: Abhijit Pradhanabhi...@qca.qualcomm.com Cc: Vasanthakumar Thiagarajanvthia...@qca.qualcomm.com Cc: Rajkumar Manoharanrmano...@qca.qualcomm.com Tested-by: Mohammed Shafi Shajakhanmoham...@qca.qualcomm.com Signed-off-by: Mohammed Shafi Shajakhanmoham...@qca.qualcomm.com Acked-by: Johannes Berg johannes.b...@intel.com --- net/mac80211/main.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/mac80211/main.c b/net/mac80211/main.c index 831a5bd..2306d75 100644 --- a/net/mac80211/main.c +++ b/net/mac80211/main.c @@ -909,6 +909,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw) wiphy_debug(local-hw.wiphy, Failed to initialize wep: %d\n, result); + ieee80211_led_init(local); + rtnl_lock(); result = ieee80211_init_rate_ctrl_alg(local, @@ -930,8 +932,6 @@ int ieee80211_register_hw(struct ieee80211_hw *hw) rtnl_unlock(); - ieee80211_led_init(local); - local-network_latency_notifier.notifier_call = ieee80211_max_network_latency; result = pm_qos_add_notifier(PM_QOS_NETWORK_LATENCY, -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
