* [PATCH v3 1/4] cfg80211: Add support to randomize TA of Public Action frames
From: Jouni Malinen @ 2017-01-12 23:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, vamsi krishna, Jouni Malinen
From: vamsi krishna <vamsin@qti.qualcomm.com>
Add support to use a random local address (Address 2 = TA in transmit
and the same address in receive functionality) for Public Action frames
in order to improve privacy of WLAN clients. Applications fill the
random transmit address in the frame buffer in the NL80211_CMD_FRAME
command. This can be used only with the drivers that indicate support
for random local address by setting the new
NL80211_EXT_FEATURE_MGMT_TX_RANDOM_TA and/or
NL80211_EXT_FEATURE_MGMT_TX_RANDOM_TA_CONNECTED in ext_features.
The driver needs to configure receive behavior to accept frames to the
specified random address during the time the frame exchange is pending
and such frames need to be acknowledged similarly to frames sent to the
local permanent address when this random address functionality is not
used.
Signed-off-by: vamsi krishna <vamsin@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
include/uapi/linux/nl80211.h | 6 ++++++
net/wireless/mlme.c | 21 +++++++++++++++++++--
2 files changed, 25 insertions(+), 2 deletions(-)
v3:
- moved to the beginning of the series since there were no pending
comments on this patch; no other changes
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 174f4b3..908886c 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4699,6 +4699,10 @@ enum nl80211_feature_flags {
* configuration (AP/mesh) with VHT rates.
* @NL80211_EXT_FEATURE_FILS_STA: This driver supports Fast Initial Link Setup
* with user space SME (NL80211_CMD_AUTHENTICATE) in station mode.
+ * @NL80211_EXT_FEATURE_MGMT_TX_RANDOM_TA: This driver supports randomized TA
+ * in @NL80211_CMD_FRAME while not associated.
+ * @NL80211_EXT_FEATURE_MGMT_TX_RANDOM_TA_CONNECTED: This driver supports
+ * randomized TA in @NL80211_CMD_FRAME while associated.
*
* @NUM_NL80211_EXT_FEATURES: number of extended features.
* @MAX_NL80211_EXT_FEATURES: highest extended feature index.
@@ -4714,6 +4718,8 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_BEACON_RATE_HT,
NL80211_EXT_FEATURE_BEACON_RATE_VHT,
NL80211_EXT_FEATURE_FILS_STA,
+ NL80211_EXT_FEATURE_MGMT_TX_RANDOM_TA,
+ NL80211_EXT_FEATURE_MGMT_TX_RANDOM_TA_CONNECTED,
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 1c63a77..b876f40 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -662,8 +662,25 @@ int cfg80211_mlme_mgmt_tx(struct cfg80211_registered_device *rdev,
return err;
}
- if (!ether_addr_equal(mgmt->sa, wdev_address(wdev)))
- return -EINVAL;
+ if (!ether_addr_equal(mgmt->sa, wdev_address(wdev))) {
+ /* Allow random TA to be used with Public Action frames if the
+ * driver has indicated support for this. Otherwise, only allow
+ * the local address to be used.
+ */
+ if (!ieee80211_is_action(mgmt->frame_control) ||
+ mgmt->u.action.category != WLAN_CATEGORY_PUBLIC)
+ return -EINVAL;
+ if (!wdev->current_bss &&
+ !wiphy_ext_feature_isset(
+ &rdev->wiphy,
+ NL80211_EXT_FEATURE_MGMT_TX_RANDOM_TA))
+ return -EINVAL;
+ if (wdev->current_bss &&
+ !wiphy_ext_feature_isset(
+ &rdev->wiphy,
+ NL80211_EXT_FEATURE_MGMT_TX_RANDOM_TA_CONNECTED))
+ return -EINVAL;
+ }
/* Transmit the Action frame as requested by user space */
return rdev_mgmt_tx(rdev, wdev, params, cookie);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] mwifiex: pcie: don't delay for sleep cookie when not required
From: Brian Norris @ 2017-01-12 21:02 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam
Cc: linux-kernel, Kalle Valo, linux-wireless, Cathy Luo, Brian Norris
In-Reply-To: <20170112210232.18554-1-briannorris@chromium.org>
Wifi modules like 8997 don't support the "sleep cookie", and so most of
the time, we just time out in the mwifiex_delay_for_sleep_cookie()
function ("max count reached while accessing sleep cookie"). This is a
waste of time, and we should skip it for modules without the sleep
cookie flag.
Additionally, this delay is sometimes counterproductive. For instance,
when PCIe ASPM is enabled, this extra delay can leave the link idle for
long enough to re-enter a low-power state even while we are trying to
wake the module, compounding an additional delay when it comes time to
read the next register (e.g., the interrupt status). On some systems,
this is detrimental to overall system latency.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
Tested on Marvell 8997, but would be good to get confirmation from Marvell.
drivers/net/wireless/marvell/mwifiex/pcie.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 435ba879ef29..11e0673617c7 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -1712,11 +1712,13 @@ static int mwifiex_pcie_process_cmd_complete(struct mwifiex_adapter *adapter)
"Write register failed\n");
return -1;
}
- mwifiex_delay_for_sleep_cookie(adapter,
- MWIFIEX_MAX_DELAY_COUNT);
- while (reg->sleep_cookie && (count++ < 10) &&
- mwifiex_pcie_ok_to_access_hw(adapter))
- usleep_range(50, 60);
+ if (reg->sleep_cookie) {
+ mwifiex_delay_for_sleep_cookie(adapter,
+ MWIFIEX_MAX_DELAY_COUNT);
+ while ((count++ < 10) &&
+ mwifiex_pcie_ok_to_access_hw(adapter))
+ usleep_range(50, 60);
+ }
mwifiex_pcie_enable_host_int(adapter);
mwifiex_process_sleep_confirm_resp(adapter, skb->data,
skb->len);
--
2.11.0.390.gc69c2f50cf-goog
^ permalink raw reply related
* [PATCH 1/2] mwifiex: pcie: use posted write to wake up firmware
From: Brian Norris @ 2017-01-12 21:02 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam
Cc: linux-kernel, Kalle Valo, linux-wireless, Cathy Luo, Brian Norris
Depending on system factors (e.g., the PCIe link PM state), the first
read to wake up the Wifi firmware can take a long time. There is no
reason to use a (blocking, non-posted) read at this point, so let's just
use a write instead. Write vs. read doesn't matter functionality-wise --
it's just a dummy operation.
This has been shown to decrease the time spent blocking in this function
on a Rockchip RK3399 SoC.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 66226c615be0..435ba879ef29 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -458,7 +458,6 @@ static void mwifiex_delay_for_sleep_cookie(struct mwifiex_adapter *adapter,
/* This function wakes up the card by reading fw_status register. */
static int mwifiex_pm_wakeup_card(struct mwifiex_adapter *adapter)
{
- u32 fw_status;
struct pcie_service_card *card = adapter->card;
const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
@@ -468,10 +467,10 @@ static int mwifiex_pm_wakeup_card(struct mwifiex_adapter *adapter)
if (reg->sleep_cookie)
mwifiex_pcie_dev_wakeup_delay(adapter);
- /* Reading fw_status register will wakeup device */
- if (mwifiex_read_reg(adapter, reg->fw_status, &fw_status)) {
+ /* Accessing fw_status register will wakeup device */
+ if (mwifiex_write_reg(adapter, reg->fw_status, 0)) {
mwifiex_dbg(adapter, ERROR,
- "Reading fw_status register failed\n");
+ "Writing fw_status register failed\n");
return -1;
}
--
2.11.0.390.gc69c2f50cf-goog
^ permalink raw reply related
* Re: [PATCH v2 12/13] wil6210: set dma mask to reflect device capability
From: merez @ 2017-01-12 20:27 UTC (permalink / raw)
To: Maya Erez
Cc: Kalle Valo, Hamad Kadmany, linux-wireless, wil6210,
linux-wireless-owner
In-Reply-To: <1484226365-10433-13-git-send-email-qca_merez@qca.qualcomm.com>
On 2017-01-12 15:06, Maya Erez wrote:
> From: Hamad Kadmany <qca_hkadmany@qca.qualcomm.com>
>
> 11ad device supports 48 bit addresses, reflect that
> by setting the dma mask accordingly.
>
> Signed-off-by: Hamad Kadmany <qca_hkadmany@qca.qualcomm.com>
> Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
> ---
Kalle, we found an issue caused by this patch. Please don't apply it.
--
Maya Erez
Qualcomm Israel, Inc. on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] mac80211: prevent skb/txq mismatch
From: Dave Taht @ 2017-01-12 19:05 UTC (permalink / raw)
To: Michal Kazior
Cc: Johannes Berg, linux-wireless, Ben Greear,
Mohammed Shafi Shajakhan
In-Reply-To: <1484231321-3179-1-git-send-email-michal.kazior@tieto.com>
Yay! This sounds like a potential fix for this?
https://bugs.lede-project.org/index.php?do=details&task_id=368
Are all the ath10k chipsets excluded by commit:
4ca1807815aa6801aaced7fdefa9edacc2521767
Still needed to be excluded?
^ permalink raw reply
* Re: [PATCH] mac80211: prevent skb/txq mismatch
From: Felix Fietkau @ 2017-01-12 18:11 UTC (permalink / raw)
To: Michal Kazior, johannes; +Cc: linux-wireless, greearb, mohammed
In-Reply-To: <1484231321-3179-1-git-send-email-michal.kazior@tieto.com>
On 2017-01-12 15:28, Michal Kazior wrote:
> Station structure is considered as not uploaded
> (to driver) until drv_sta_state() finishes. This
> call is however done after the structure is
> attached to mac80211 internal lists and hashes.
> This means mac80211 can lookup (and use) station
> structure before it is uploaded to a driver.
>
> If this happens (structure exists, but
> sta->uploaded is false) fast_tx path can still be
> taken. Deep in the fastpath call the sta->uploaded
> is checked against to derive "pubsta" argument for
> ieee80211_get_txq(). If sta->uploaded is false
> (and sta is actually non-NULL) ieee80211_get_txq()
> effectively downgraded to vif->txq.
>
> At first glance this may look innocent but coerces
> mac80211 into a state that is almost guaranteed
> (codel may drop offending skb) to crash because a
> station-oriented skb gets queued up on
> vif-oriented txq. The ieee80211_tx_dequeue() ends
> up looking at info->control.flags and tries to use
> txq->sta which in the fail case is NULL.
>
> It's probably pointless to pretend one can
> downgrade skb from sta-txq to vif-txq.
>
> Only drivers using wake_tx_queue were affected.
>
> Example crash dump before fix:
>
> Unable to handle kernel paging request at virtual address ffffe26c
> PC is at ieee80211_tx_dequeue+0x204/0x690 [mac80211]
> [<bf4252a4>] (ieee80211_tx_dequeue [mac80211]) from
> [<bf4b1388>] (ath10k_mac_tx_push_txq+0x54/0x1c0 [ath10k_core])
> [<bf4b1388>] (ath10k_mac_tx_push_txq [ath10k_core]) from
> [<bf4bdfbc>] (ath10k_htt_txrx_compl_task+0xd78/0x11d0 [ath10k_core])
> [<bf4bdfbc>] (ath10k_htt_txrx_compl_task [ath10k_core])
> [<bf51c5a4>] (ath10k_pci_napi_poll+0x54/0xe8 [ath10k_pci])
> [<bf51c5a4>] (ath10k_pci_napi_poll [ath10k_pci]) from
> [<c0572e90>] (net_rx_action+0xac/0x160)
>
> Reported-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Acked-by: Felix Fietkau <nbd@nbd.name>
^ permalink raw reply
* [PATCH] Revert "bcma: init serial console directly from ChipCommon code"
From: Rafał Miłecki @ 2017-01-12 17:44 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Felix Fietkau, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
This reverts commit 4c81acab3816 ("bcma: init serial console directly
from ChipCommon code") as it broke IRQ assignment. Getting IRQ with
bcma_core_irq helper on SoC requires MIPS core to be set. It happens
*after* ChipCommon initialization so we can't do this so early.
This fixes a regression but it seems noone noticed it for about a year.
It could be it was because serial was still somehow working, just
without IRQs. It doesn't look like a critical patch / fix.
Reported-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/bcma/bcma_private.h | 3 +++
drivers/bcma/driver_chipcommon.c | 11 +++--------
drivers/bcma/driver_mips.c | 3 +++
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
index f642c42..168fa17 100644
--- a/drivers/bcma/bcma_private.h
+++ b/drivers/bcma/bcma_private.h
@@ -45,6 +45,9 @@ int bcma_sprom_get(struct bcma_bus *bus);
void bcma_core_chipcommon_early_init(struct bcma_drv_cc *cc);
void bcma_core_chipcommon_init(struct bcma_drv_cc *cc);
void bcma_chipco_bcm4331_ext_pa_lines_ctl(struct bcma_drv_cc *cc, bool enable);
+#ifdef CONFIG_BCMA_DRIVER_MIPS
+void bcma_chipco_serial_init(struct bcma_drv_cc *cc);
+#endif /* CONFIG_BCMA_DRIVER_MIPS */
/* driver_chipcommon_b.c */
int bcma_core_chipcommon_b_init(struct bcma_drv_cc_b *ccb);
diff --git a/drivers/bcma/driver_chipcommon.c b/drivers/bcma/driver_chipcommon.c
index b4f6520..62f5bfa 100644
--- a/drivers/bcma/driver_chipcommon.c
+++ b/drivers/bcma/driver_chipcommon.c
@@ -15,8 +15,6 @@
#include <linux/platform_device.h>
#include <linux/bcma/bcma.h>
-static void bcma_chipco_serial_init(struct bcma_drv_cc *cc);
-
static inline u32 bcma_cc_write32_masked(struct bcma_drv_cc *cc, u16 offset,
u32 mask, u32 value)
{
@@ -186,9 +184,6 @@ void bcma_core_chipcommon_early_init(struct bcma_drv_cc *cc)
if (cc->capabilities & BCMA_CC_CAP_PMU)
bcma_pmu_early_init(cc);
- if (IS_BUILTIN(CONFIG_BCM47XX) && bus->hosttype == BCMA_HOSTTYPE_SOC)
- bcma_chipco_serial_init(cc);
-
if (bus->hosttype == BCMA_HOSTTYPE_SOC)
bcma_core_chipcommon_flash_detect(cc);
@@ -378,9 +373,9 @@ u32 bcma_chipco_gpio_pulldown(struct bcma_drv_cc *cc, u32 mask, u32 value)
return res;
}
-static void bcma_chipco_serial_init(struct bcma_drv_cc *cc)
+#ifdef CONFIG_BCMA_DRIVER_MIPS
+void bcma_chipco_serial_init(struct bcma_drv_cc *cc)
{
-#if IS_BUILTIN(CONFIG_BCM47XX)
unsigned int irq;
u32 baud_base;
u32 i;
@@ -422,5 +417,5 @@ static void bcma_chipco_serial_init(struct bcma_drv_cc *cc)
ports[i].baud_base = baud_base;
ports[i].reg_shift = 0;
}
-#endif /* CONFIG_BCM47XX */
}
+#endif /* CONFIG_BCMA_DRIVER_MIPS */
diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
index 96f1713..89af807 100644
--- a/drivers/bcma/driver_mips.c
+++ b/drivers/bcma/driver_mips.c
@@ -278,9 +278,12 @@ static void bcma_core_mips_nvram_init(struct bcma_drv_mips *mcore)
void bcma_core_mips_early_init(struct bcma_drv_mips *mcore)
{
+ struct bcma_bus *bus = mcore->core->bus;
+
if (mcore->early_setup_done)
return;
+ bcma_chipco_serial_init(&bus->drv_cc);
bcma_core_mips_nvram_init(mcore);
mcore->early_setup_done = true;
--
2.10.1
^ permalink raw reply related
* Re: [PATCH] ath10k: prevent sta pointer rcu violation
From: Michal Kazior @ 2017-01-12 16:18 UTC (permalink / raw)
To: Johannes Berg
Cc: Kalle Valo, linux-wireless, ath10k@lists.infradead.org,
Ben Greear, Mohammed Shafi Shajakhan
In-Reply-To: <1484235986.19860.1.camel@sipsolutions.net>
On 12 January 2017 at 16:46, Johannes Berg <johannes@sipsolutions.net> wrot=
e:
> On Thu, 2017-01-12 at 16:14 +0100, Michal Kazior wrote:
>> Station pointers are RCU protected so driver must
>> be extra careful if it tries to store them
>> internally for later use outside of the RCU
>> section it obtained it in.
>>
>> It was possible for station teardown to race with
>> some htt events. The possible outcome could be a
>> use-after-free and a crash.
>>
>> Only peer-flow-control capable firmware was
>> affected (so hardware-wise qca99x0 and qca4019).
>>
>> This could be done in sta_state() itself via
>> explicit synchronize_net() call but there's
>> already a convenient sta_pre_rcu_remove() op that
>> can be hooked up to avoid extra rcu stall.
>
> I don't think this makes sense. You're not using RCU-protected pointers
> to the stations yourself, all accesses to them are locked under the
> &ar->data_lock. As a consequence, you can't have any need for waiting
> for a grace period. Since you also remove the pointer (under lock) when
> the station gets removed, I don't think RCU can be the problem?
Unless you then continue to use that sta pointer after you release
data_lock. Consider this:
> CPU0 CPU1
> 1 synchronize_net()
> 2 drv_sta_state()
> 3 htt_fetch_ind(pid,tid) called
> 4 rcu_read_lock()
> 5 get(data_lock)
> 6 txq=3Dpeers[pid]->sta->txq[tid]
> 7 put(data_lock)
> 8 get(data_lock)
> 9 peer->sta=3D0
> 10 put(data_lock)
> 11 kfree(sta)
> 12 ieee80211_tx_dequeue(txq)
Even though there's no code like (9) per se you can think of it as
anything that tries to "remove" the peer--sta association (ath10k_peer
is removed implicitly via wmi peer delete command and waiting for htt
event completion).
Holding data_lock for the entire duration of handling fetch indication
isn't really good for performance so it's better to fix RCU handling.
Micha=C5=82
^ permalink raw reply
* Re: [PATCH] ath10k: prevent sta pointer rcu violation
From: Johannes Berg @ 2017-01-12 15:46 UTC (permalink / raw)
To: Michal Kazior, kvalo; +Cc: linux-wireless, ath10k, greearb, mohammed
In-Reply-To: <1484234070-7431-1-git-send-email-michal.kazior@tieto.com>
On Thu, 2017-01-12 at 16:14 +0100, Michal Kazior wrote:
> Station pointers are RCU protected so driver must
> be extra careful if it tries to store them
> internally for later use outside of the RCU
> section it obtained it in.
>
> It was possible for station teardown to race with
> some htt events. The possible outcome could be a
> use-after-free and a crash.
>
> Only peer-flow-control capable firmware was
> affected (so hardware-wise qca99x0 and qca4019).
>
> This could be done in sta_state() itself via
> explicit synchronize_net() call but there's
> already a convenient sta_pre_rcu_remove() op that
> can be hooked up to avoid extra rcu stall.
I don't think this makes sense. You're not using RCU-protected pointers
to the stations yourself, all accesses to them are locked under the
&ar->data_lock. As a consequence, you can't have any need for waiting
for a grace period. Since you also remove the pointer (under lock) when
the station gets removed, I don't think RCU can be the problem?
johannes
^ permalink raw reply
* [PATCH] ath10k: prevent sta pointer rcu violation
From: Michal Kazior @ 2017-01-12 15:14 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, ath10k, greearb, mohammed, Michal Kazior
Station pointers are RCU protected so driver must
be extra careful if it tries to store them
internally for later use outside of the RCU
section it obtained it in.
It was possible for station teardown to race with
some htt events. The possible outcome could be a
use-after-free and a crash.
Only peer-flow-control capable firmware was
affected (so hardware-wise qca99x0 and qca4019).
This could be done in sta_state() itself via
explicit synchronize_net() call but there's
already a convenient sta_pre_rcu_remove() op that
can be hooked up to avoid extra rcu stall.
The peer->sta pointer itself can't be set to
NULL/ERR_PTR because it is later used in
sta_state() for extra sanity checks.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/mac.c | 18 ++++++++++++++++++
2 files changed, 19 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index c7664d6569fa..1ab589296dff 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -314,6 +314,7 @@ struct ath10k_peer {
struct ieee80211_vif *vif;
struct ieee80211_sta *sta;
+ bool removed;
int vdev_id;
u8 addr[ETH_ALEN];
DECLARE_BITMAP(peer_ids, ATH10K_MAX_NUM_PEER_IDS);
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d1b7edba5e49..aa91f55b35a4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3774,6 +3774,9 @@ struct ieee80211_txq *ath10k_mac_txq_lookup(struct ath10k *ar,
if (!peer)
return NULL;
+ if (peer->removed)
+ return NULL;
+
if (peer->sta)
return peer->sta->txq[tid];
else if (peer->vif)
@@ -7476,6 +7479,20 @@ ath10k_mac_op_switch_vif_chanctx(struct ieee80211_hw *hw,
return 0;
}
+static void ath10k_mac_op_sta_pre_rcu_remove(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta)
+{
+ struct ath10k *ar;
+ struct ath10k_peer *peer;
+
+ ar = hw->priv;
+
+ list_for_each_entry(peer, &ar->peers, list)
+ if (peer->sta == sta)
+ peer->removed = true;
+}
+
static const struct ieee80211_ops ath10k_ops = {
.tx = ath10k_mac_op_tx,
.wake_tx_queue = ath10k_mac_op_wake_tx_queue,
@@ -7516,6 +7533,7 @@ static const struct ieee80211_ops ath10k_ops = {
.assign_vif_chanctx = ath10k_mac_op_assign_vif_chanctx,
.unassign_vif_chanctx = ath10k_mac_op_unassign_vif_chanctx,
.switch_vif_chanctx = ath10k_mac_op_switch_vif_chanctx,
+ .sta_pre_rcu_remove = ath10k_mac_op_sta_pre_rcu_remove,
CFG80211_TESTMODE_CMD(ath10k_tm_cmd)
--
2.1.4
^ permalink raw reply related
* Re: [next] rtlwifi: rtl8192de: fix missing curly braces
From: Kalle Valo @ 2017-01-12 15:11 UTC (permalink / raw)
To: Vincent
Cc: devel, linux-wireless, Vincent Stehlé, Larry Finger,
Joe Perches, Ping-Ke Shih
In-Reply-To: <20170110095521.4410-1-vincent.stehle@laposte.net>
Vincent <vincent.stehle@laposte.net> wrote:
> Restore some curly braces that have been removed in commit c93ac39da006457f
> ("rtlwifi: Remove some redundant code") while removing redundant messages
> and extraneous braces.
>
> This fixes the following smatch warning:
>
> drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c:326 rtl92d_download_fw() warn: curly braces intended?
>
> ...and the following coccinelle warning:
>
> drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c:325:2-38: code aligned with following code on line 326
>
> Fixes: c93ac39da006457f ("rtlwifi: Remove some redundant code")
> Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
> Cc: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: Joe Perches <joe@perches.com>
> Cc: Ping-Ke Shih <pkshih@realtek.com>
Larry also sent a fix:
rtlwifi: rtl8192de: Remove a pointless goto
https://patchwork.kernel.org/patch/9508121/
Patch set to Superseded.
--
https://patchwork.kernel.org/patch/9506837/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout
From: Malinen, Jouni @ 2017-01-12 15:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, Kushwaha, Purushottam
In-Reply-To: <1484231540.5391.6.camel@sipsolutions.net>
On Thu, Jan 12, 2017 at 03:32:20PM +0100, Johannes Berg wrote:
>=20
> > We don't.. This discussion here is about the C API where we cannot
> > remove the argument from the call without adding yet another inline
> > wrapper, but the actual function that generates the netlink message
> > does not add the timeout reason attribute for success or explicit
> > rejection cases.
>=20
> Ah. But we can just say here then that it's ignored in those cases, and
> not really worry about it?
Sure, I'll update the comment to say that.
--=20
Jouni Malinen PGP id EFC895FA=
^ permalink raw reply
* Re: mwifiex: don't include mac80211.h
From: Kalle Valo @ 2017-01-12 15:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20170105123835.20995-1-johannes@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> This driver doesn't use mac80211, so it shouldn't include mac80211.h,
> include only the necessary cfg80211.h instead.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Depends on:
3db5e3e707eb wireless: move IEEE80211_NUM_ACS to ieee80211.h
Currently in mac80211-next.
Patch set to Awaiting Upstream.
--
https://patchwork.kernel.org/patch/9498969/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
From: Kalle Valo @ 2017-01-12 14:55 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
rajatja@google.com, briannorris@google.com,
dmitry.torokhov@gmail.com, Xinming Hu
In-Reply-To: <e03f76e98fae4ce1a6cf254a1838574c@SC-EXCH04.marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
>> But these didn't. Can you please rebase these and resubmit in one
>> patchset? Less conflicts that way.
>>
>
> The problem here is you tried to apply the patches in reverse order. Sorry for the confusion.
> Please apply pending patches in below order.
>
> [v3,1/5] mwifiex: don't wait for main_process in shutdown_drv --- Apply this patch first.
> [v3,2/5] mwifiex: do not free firmware dump memory in shutdown_drv
> [v3,3/5] mwifiex: get rid of drv_info* adapter variables
> [v3,4/5] mwifiex: wait firmware dump complete during card remove process
> [v3,5/5] mwifiex: move pcie_work and related variables inside card
>
> [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
> [2/2] mwifiex: get rid of global user_rmmod flag
>
> mwifiex: use module_*_driver helper macros
>
> [1/5] mwifiex: get rid of mwifiex_do_flr wrapper
> [2/5] mwifiex: cleanup in PCIe flr code path
> [3/5] mwifiex: sdio card reset enhancement
> [4/5] mwifiex: get rid of __mwifiex_sdio_remove helper
> [5/5] mwifiex: get rid of global save_adapter and sdio_work
Thanks, now I was able to apply these but please do double check the
result in wireless-drivers-next.
I also noticed a new warning:
drivers/net/wireless/marvell/mwifiex/pcie.c: In function 'mwifiex_pcie_remove':
drivers/net/wireless/marvell/mwifiex/pcie.c:303:5: warning: 'fw_status'
may be used uninitialized in this function [-Wmaybe-uninitialized]
if (fw_status == FIRMWARE_READY_PCIE && !adapter->mfg_mode) {
Actually I'm not sure if this warning was caused by these patches as I
have recently updated my ancient gcc to a newer one (5.4.0), but please
take a look and send a fix if it's a valid warning.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mac80211: prevent skb/txq mismatch
From: Mohammed Shafi Shajakhan @ 2017-01-12 14:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: Michal Kazior, linux-wireless, greearb, mohammed
In-Reply-To: <1484232680.5391.8.camel@sipsolutions.net>
On Thu, Jan 12, 2017 at 03:51:20PM +0100, Johannes Berg wrote:
> On Thu, 2017-01-12 at 20:15 +0530, Mohammed Shafi Shajakhan wrote:
> >
> > > Reported-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> > > Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
> >
> > Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> That makes no sense, you're not handling the patch in any way. You can
> say Tested-by, or Acked-by if you like, but not S-o-b. See the DCO
> (Documentation/SubmittingPatches)
>
apologies for that, I assumed we can add Signed-off on the fly
^ permalink raw reply
* Re: [v3,1/5] mwifiex: don't wait for main_process in shutdown_drv
From: Kalle Valo @ 2017-01-12 14:45 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1479301749-14803-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> main_process is not expected to be running when shutdown_drv function
> is called. currently we wait for main_process completion in the
> function.
>
> Actually the caller has already made sure main_process is completed by
> performing below actions.
> (1) disable interrupts in if_ops->disable_int.
> (2) set adapter->surprise_removed = true, main_process wont be queued.
> (3) mwifiex_terminate_workqueue(adapter), wait for workqueue to be
> completed.
>
> This patch removes redundant wait code and takes care of related
> cleanup.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
5 patches applied to wireless-drivers-next.git, thanks.
5bf15e3fb85d mwifiex: don't wait for main_process in shutdown_drv
fb45bd0c6d6b mwifiex: do not free firmware dump memory in shutdown_drv
d27121fca129 mwifiex: get rid of drv_info* adapter variables
41efaf5824e7 mwifiex: wait firmware dump complete during card remove process
3860e5e39532 mwifiex: move pcie_work and related variables inside card
--
https://patchwork.kernel.org/patch/9431485/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mac80211: prevent skb/txq mismatch
From: Mohammed Shafi Shajakhan @ 2017-01-12 14:45 UTC (permalink / raw)
To: Michal Kazior; +Cc: johannes, linux-wireless, greearb, mohammed
In-Reply-To: <1484231321-3179-1-git-send-email-michal.kazior@tieto.com>
On Thu, Jan 12, 2017 at 03:28:41PM +0100, Michal Kazior wrote:
> Station structure is considered as not uploaded
> (to driver) until drv_sta_state() finishes. This
> call is however done after the structure is
> attached to mac80211 internal lists and hashes.
> This means mac80211 can lookup (and use) station
> structure before it is uploaded to a driver.
>
> If this happens (structure exists, but
> sta->uploaded is false) fast_tx path can still be
> taken. Deep in the fastpath call the sta->uploaded
> is checked against to derive "pubsta" argument for
> ieee80211_get_txq(). If sta->uploaded is false
> (and sta is actually non-NULL) ieee80211_get_txq()
> effectively downgraded to vif->txq.
>
> At first glance this may look innocent but coerces
> mac80211 into a state that is almost guaranteed
> (codel may drop offending skb) to crash because a
> station-oriented skb gets queued up on
> vif-oriented txq. The ieee80211_tx_dequeue() ends
> up looking at info->control.flags and tries to use
> txq->sta which in the fail case is NULL.
>
> It's probably pointless to pretend one can
> downgrade skb from sta-txq to vif-txq.
>
> Only drivers using wake_tx_queue were affected.
>
> Example crash dump before fix:
>
> Unable to handle kernel paging request at virtual address ffffe26c
> PC is at ieee80211_tx_dequeue+0x204/0x690 [mac80211]
> [<bf4252a4>] (ieee80211_tx_dequeue [mac80211]) from
> [<bf4b1388>] (ath10k_mac_tx_push_txq+0x54/0x1c0 [ath10k_core])
> [<bf4b1388>] (ath10k_mac_tx_push_txq [ath10k_core]) from
> [<bf4bdfbc>] (ath10k_htt_txrx_compl_task+0xd78/0x11d0 [ath10k_core])
> [<bf4bdfbc>] (ath10k_htt_txrx_compl_task [ath10k_core])
> [<bf51c5a4>] (ath10k_pci_napi_poll+0x54/0xe8 [ath10k_pci])
> [<bf51c5a4>] (ath10k_pci_napi_poll [ath10k_pci]) from
> [<c0572e90>] (net_rx_action+0xac/0x160)
>
> Reported-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> ---
> net/mac80211/tx.c | 17 +++++++----------
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 4dea18be385c..c77fcf83d004 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -1244,13 +1244,16 @@ ieee80211_tx_prepare(struct ieee80211_sub_if_data *sdata,
>
> static struct txq_info *ieee80211_get_txq(struct ieee80211_local *local,
> struct ieee80211_vif *vif,
> - struct ieee80211_sta *pubsta,
> + struct sta_info *sta,
> struct sk_buff *skb)
> {
> struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> struct ieee80211_txq *txq = NULL;
>
> + if (sta && !sta->uploaded)
> + return NULL;
> +
> if ((info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) ||
> (info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE))
> return NULL;
> @@ -1258,10 +1261,10 @@ static struct txq_info *ieee80211_get_txq(struct ieee80211_local *local,
> if (!ieee80211_is_data(hdr->frame_control))
> return NULL;
>
> - if (pubsta) {
> + if (sta) {
> u8 tid = skb->priority & IEEE80211_QOS_CTL_TID_MASK;
>
> - txq = pubsta->txq[tid];
> + txq = sta->sta.txq[tid];
> } else if (vif) {
> txq = vif->txq;
> }
> @@ -1504,23 +1507,17 @@ static bool ieee80211_queue_skb(struct ieee80211_local *local,
> struct fq *fq = &local->fq;
> struct ieee80211_vif *vif;
> struct txq_info *txqi;
> - struct ieee80211_sta *pubsta;
>
> if (!local->ops->wake_tx_queue ||
> sdata->vif.type == NL80211_IFTYPE_MONITOR)
> return false;
>
> - if (sta && sta->uploaded)
> - pubsta = &sta->sta;
> - else
> - pubsta = NULL;
> -
> if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
> sdata = container_of(sdata->bss,
> struct ieee80211_sub_if_data, u.ap);
>
> vif = &sdata->vif;
> - txqi = ieee80211_get_txq(local, vif, pubsta, skb);
> + txqi = ieee80211_get_txq(local, vif, sta, skb);
>
> if (!txqi)
> return false;
> --
> 2.1.4
>
^ permalink raw reply
* Re: [PATCH] mac80211: prevent skb/txq mismatch
From: Johannes Berg @ 2017-01-12 14:51 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan, Michal Kazior; +Cc: linux-wireless, greearb, mohammed
In-Reply-To: <20170112144527.GA10941@atheros-ThinkPad-T61>
On Thu, 2017-01-12 at 20:15 +0530, Mohammed Shafi Shajakhan wrote:
>
> > Reported-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> > Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
That makes no sense, you're not handling the patch in any way. You can
say Tested-by, or Acked-by if you like, but not S-o-b. See the DCO
(Documentation/SubmittingPatches)
johannes
^ permalink raw reply
* Re: [1/5] mwifiex: get rid of mwifiex_do_flr wrapper
From: Kalle Valo @ 2017-01-12 14:49 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1481724651-30397-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> This patch gets rid of mwifiex_do_flr. We will call
> mwifiex_shutdown_sw() and mwifiex_reinit_sw() directly.
> These two general purpose functions will be useful for
> sdio card reset handler.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
5 patches applied to wireless-drivers-next.git, thanks.
8750ab6236b0 mwifiex: get rid of mwifiex_do_flr wrapper
ec750f1082d7 mwifiex: cleanup in PCIe flr code path
c742e623e941 mwifiex: sdio card reset enhancement
a7513a4fa919 mwifiex: get rid of __mwifiex_sdio_remove helper
cc75c577806a mwifiex: get rid of global save_adapter and sdio_work
--
https://patchwork.kernel.org/patch/9474231/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mwifiex: use module_*_driver helper macros
From: Kalle Valo @ 2017-01-12 14:48 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, dmitry.torokhov, Amitkumar Karwar
In-Reply-To: <1480597700-2456-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> After user_rmmod global flag removal, *_init_module() and
> *_cleanup_module() have become just a wrapper functions.
> We will get rid of them with the help of module_*_driver() macros.
>
> For pcie, existing ".init_if" handler has same name as what
> module_pcie_driver() macro will create. Let's rename it to
> avoid conflict.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Patch applied to wireless-drivers-next.git, thanks.
c0e6aa426823 mwifiex: use module_*_driver helper macros
--
https://patchwork.kernel.org/patch/9456135/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
From: Kalle Valo @ 2017-01-12 14:46 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1480517537-9920-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> Next patch in this series is going to use mwifiex_read_reg() in remove
> handlers. The changes here are prerequisites to avoid forward
> declarations.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
2 patches applied to wireless-drivers-next.git, thanks.
90ff71f95575 mwifiex: code rearrangement in pcie.c and sdio.c
045f0c1b5e26 mwifiex: get rid of global user_rmmod flag
--
https://patchwork.kernel.org/patch/9454491/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout
From: Johannes Berg @ 2017-01-12 14:32 UTC (permalink / raw)
To: Malinen, Jouni; +Cc: linux-wireless@vger.kernel.org, Kushwaha, Purushottam
In-Reply-To: <20170112142926.GA19489@jouni.qca.qualcomm.com>
> We don't.. This discussion here is about the C API where we cannot
> remove the argument from the call without adding yet another inline
> wrapper, but the actual function that generates the netlink message
> does not add the timeout reason attribute for success or explicit
> rejection cases.
Ah. But we can just say here then that it's ignored in those cases, and
not really worry about it?
johannes
^ permalink raw reply
* Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout
From: Malinen, Jouni @ 2017-01-12 14:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, Kushwaha, Purushottam
In-Reply-To: <1484229979.5391.5.camel@sipsolutions.net>
On Thu, Jan 12, 2017 at 03:06:19PM +0100, Johannes Berg wrote:
> On Thu, 2017-01-12 at 13:58 +0000, Malinen, Jouni wrote:
> >=20
> > > I think this description is misleading - one could easily
> > > understand
> > > "for other cases" to indicate for the cases that the AP did
> > > explicitly
> > > reject it, but that's obviously not true.
> >=20
> > Well, the expectation here really was that the reason for the timeout
> > would be known if there was a timeout and the unspecified value would
> > be used in all other cases, i.e., in cases where the AP did indeed
> > explicitly reject the connection.
>=20
> Hmm. It doesn't really make sense to include the attribute in that case
> at all though, does it?
We don't.. This discussion here is about the C API where we cannot
remove the argument from the call without adding yet another inline
wrapper, but the actual function that generates the netlink message does
not add the timeout reason attribute for success or explicit rejection
cases.
> > Sure, I can say that NL80211_TIMEOUT_UNSPECIFIED is used when the
> > reason for the timeout is not known or there was an explicit
> > rejection instead of a timeout.
>=20
> See above - why even think about this attribute in the successful case?
See above.. C API. Or do you want yet another wrapper for
cfg80211_connect_bss() to be added while trying to hide
cfg80211_connect_bss() from drivers somehow?
> Fair enough. I still think we should not include the
> ATTR_TIMEOUT_REASON for the successful or explicit rejection case at
> all though. We can really even distinguish that in the low-level
> function, I think?
nl80211_send_connect_result() already does this:
(status < 0 &&
(nla_put_flag(msg, NL80211_ATTR_TIMED_OUT) ||
nla_put_u32(msg, NL80211_ATTR_TIMEOUT_REASON, timeout_reason))) |=
|
That status =3D=3D -1 special case used to be internal special value within
cfg80211, but it gets exposed to drivers since we use
cfg80211_connect_bss() both internally and from drivers instead of
having separate wrappers for drivers for cases where the bss entry is
explicitly specified.
--=20
Jouni Malinen PGP id EFC895FA=
^ permalink raw reply
* [PATCH] mac80211: prevent skb/txq mismatch
From: Michal Kazior @ 2017-01-12 14:28 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, greearb, mohammed, Michal Kazior
Station structure is considered as not uploaded
(to driver) until drv_sta_state() finishes. This
call is however done after the structure is
attached to mac80211 internal lists and hashes.
This means mac80211 can lookup (and use) station
structure before it is uploaded to a driver.
If this happens (structure exists, but
sta->uploaded is false) fast_tx path can still be
taken. Deep in the fastpath call the sta->uploaded
is checked against to derive "pubsta" argument for
ieee80211_get_txq(). If sta->uploaded is false
(and sta is actually non-NULL) ieee80211_get_txq()
effectively downgraded to vif->txq.
At first glance this may look innocent but coerces
mac80211 into a state that is almost guaranteed
(codel may drop offending skb) to crash because a
station-oriented skb gets queued up on
vif-oriented txq. The ieee80211_tx_dequeue() ends
up looking at info->control.flags and tries to use
txq->sta which in the fail case is NULL.
It's probably pointless to pretend one can
downgrade skb from sta-txq to vif-txq.
Only drivers using wake_tx_queue were affected.
Example crash dump before fix:
Unable to handle kernel paging request at virtual address ffffe26c
PC is at ieee80211_tx_dequeue+0x204/0x690 [mac80211]
[<bf4252a4>] (ieee80211_tx_dequeue [mac80211]) from
[<bf4b1388>] (ath10k_mac_tx_push_txq+0x54/0x1c0 [ath10k_core])
[<bf4b1388>] (ath10k_mac_tx_push_txq [ath10k_core]) from
[<bf4bdfbc>] (ath10k_htt_txrx_compl_task+0xd78/0x11d0 [ath10k_core])
[<bf4bdfbc>] (ath10k_htt_txrx_compl_task [ath10k_core])
[<bf51c5a4>] (ath10k_pci_napi_poll+0x54/0xe8 [ath10k_pci])
[<bf51c5a4>] (ath10k_pci_napi_poll [ath10k_pci]) from
[<c0572e90>] (net_rx_action+0xac/0x160)
Reported-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
net/mac80211/tx.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 4dea18be385c..c77fcf83d004 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1244,13 +1244,16 @@ ieee80211_tx_prepare(struct ieee80211_sub_if_data *sdata,
static struct txq_info *ieee80211_get_txq(struct ieee80211_local *local,
struct ieee80211_vif *vif,
- struct ieee80211_sta *pubsta,
+ struct sta_info *sta,
struct sk_buff *skb)
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_txq *txq = NULL;
+ if (sta && !sta->uploaded)
+ return NULL;
+
if ((info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) ||
(info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE))
return NULL;
@@ -1258,10 +1261,10 @@ static struct txq_info *ieee80211_get_txq(struct ieee80211_local *local,
if (!ieee80211_is_data(hdr->frame_control))
return NULL;
- if (pubsta) {
+ if (sta) {
u8 tid = skb->priority & IEEE80211_QOS_CTL_TID_MASK;
- txq = pubsta->txq[tid];
+ txq = sta->sta.txq[tid];
} else if (vif) {
txq = vif->txq;
}
@@ -1504,23 +1507,17 @@ static bool ieee80211_queue_skb(struct ieee80211_local *local,
struct fq *fq = &local->fq;
struct ieee80211_vif *vif;
struct txq_info *txqi;
- struct ieee80211_sta *pubsta;
if (!local->ops->wake_tx_queue ||
sdata->vif.type == NL80211_IFTYPE_MONITOR)
return false;
- if (sta && sta->uploaded)
- pubsta = &sta->sta;
- else
- pubsta = NULL;
-
if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
sdata = container_of(sdata->bss,
struct ieee80211_sub_if_data, u.ap);
vif = &sdata->vif;
- txqi = ieee80211_get_txq(local, vif, pubsta, skb);
+ txqi = ieee80211_get_txq(local, vif, sta, skb);
if (!txqi)
return false;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout
From: Johannes Berg @ 2017-01-12 14:06 UTC (permalink / raw)
To: Malinen, Jouni; +Cc: linux-wireless@vger.kernel.org, Kushwaha, Purushottam
In-Reply-To: <20170112135843.GB17983@jouni.qca.qualcomm.com>
On Thu, 2017-01-12 at 13:58 +0000, Malinen, Jouni wrote:
>
> > I think this description is misleading - one could easily
> > understand
> > "for other cases" to indicate for the cases that the AP did
> > explicitly
> > reject it, but that's obviously not true.
>
> Well, the expectation here really was that the reason for the timeout
> would be known if there was a timeout and the unspecified value would
> be used in all other cases, i.e., in cases where the AP did indeed
> explicitly reject the connection.
Hmm. It doesn't really make sense to include the attribute in that case
at all though, does it?
> I guess there might be a driver where the connect request goes into
> firmware implementation and the driver would not know whether the
> operation failed due to authentication frame or association frame
> timeout out.. Implementation itself would still be fine, but I agree
> that it might be a bit confusing the try to interpret the description
> here on what the driver should do.
>
> > Perhaps that could be reworded, to say it's used when it's not
> > known,
> > or such? I'd not indicate the value (0) either, just specify the
> > name,
> > and put a % in front to get better formatting for it please.
>
> Sure, I can say that NL80211_TIMEOUT_UNSPECIFIED is used when the
> reason for the timeout is not known or there was an explicit
> rejection instead of a timeout.
See above - why even think about this attribute in the successful case?
> That said, cfg80211_connect_bss() is really currently documented to
> be used only for the success case just like
> cfg80211_connect_result(). In other words, if a driver were to call
> cfg80211_connect_bss(), it should really always specify
> NL80211_TIMEOUT_UNSPECIFIED here based on the current documented us.
> All failure would then need to be reported with
> cfg80211_connect_timeout() for the timeout case or by not following
> the documentation and calling cfg80211_connect_result() or
> cfg80211_connect_bss() for rejection cases. That said, the
> documentation for the connect() callback function does describe the
> failure case behavior correctly. I think I cleaned up that at some
> point, but did not update the function documentation at the same
> time.
Ok.
> So it looks like some additional cleanup would be needed to make the
> documentation actually match what we expect the driver to do for
> rejection cases.. I'd like to leave it out from this specific patch
> and address the cleanup of existing failure case description in a
> separate patch.
Fair enough. I still think we should not include the
ATTR_TIMEOUT_REASON for the successful or explicit rejection case at
all though. We can really even distinguish that in the low-level
function, I think?
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox