[PATCH] mac80211: fix GFP_KERNEL under tasklet context
From: Yan-Hsuan Chuang
cfg80211_sta_opmode_change_notify needs a gfp_t flag to hint the nl80211
stack when allocating new skb, but it is called under tasklet context
here with GFP_KERNEL and kernel will yield a warning about it.
Fixes: ff84e7bfe176 ("mac80211: Add support to notify ht/vht opmode
modification.")
Signed-off-by: Yan-Hsuan Chuang
---
net/mac80211/rx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 64742f2..03d3964f 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3028,7 +3028,7 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)
cfg80211_sta_opmode_change_notify(sdata->dev,
rx->sta->addr,
_opmode,
- GFP_KERNEL);
+ GFP_ATOMIC);
goto handled;
}
case WLAN_HT_ACTION_NOTIFY_CHANWIDTH: {
@@ -3065,7 +3065,7 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)
cfg80211_sta_opmode_change_notify(sdata->dev,
rx->sta->addr,
_opmode,
- GFP_KERNEL);
+ GFP_ATOMIC);
goto handled;
}
default:
--
2.7.4
[PATCH 2/2] mt76x0: pci: add DFS support
Introduce dfs support in mt76x0e driver and unlock radar channels
Signed-off-by: Lorenzo Bianconi
---
.../net/wireless/mediatek/mt76/mt76x0/main.c | 11 +--
.../net/wireless/mediatek/mt76/mt76x0/phy.c | 4 +++
.../net/wireless/mediatek/mt76/mt76x02_dfs.c | 31 +--
.../net/wireless/mediatek/mt76/mt76x02_dfs.h | 1 +
.../net/wireless/mediatek/mt76/mt76x02_util.c | 5 +++
.../wireless/mediatek/mt76/mt76x2/pci_init.c | 7 -
.../net/wireless/mediatek/mt76/mt76x2/phy.c | 23 +-
7 files changed, 49 insertions(+), 33 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
b/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
index cd1a1225ad8b..a803a9b6a4c5 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/main.c
@@ -22,7 +22,10 @@ mt76x0_set_channel(struct mt76x02_dev *dev, struct
cfg80211_chan_def *chandef)
int ret;
cancel_delayed_work_sync(>cal_work);
- tasklet_disable(>pre_tbtt_tasklet);
+ if (mt76_is_mmio(dev)) {
+ tasklet_disable(>pre_tbtt_tasklet);
+ tasklet_disable(>dfs_pd.dfs_tasklet);
+ }
mt76_set_channel(>mt76);
ret = mt76x0_phy_set_channel(dev, chandef);
@@ -31,7 +34,11 @@ mt76x0_set_channel(struct mt76x02_dev *dev, struct
cfg80211_chan_def *chandef)
mt76_rr(dev, MT_CH_IDLE);
mt76_rr(dev, MT_CH_BUSY);
- tasklet_enable(>pre_tbtt_tasklet);
+ if (mt76_is_mmio(dev)) {
+ mt76x02_dfs_init_params(dev);
+ tasklet_enable(>pre_tbtt_tasklet);
+ tasklet_enable(>dfs_pd.dfs_tasklet);
+ }
mt76_txq_schedule_all(>mt76);
return ret;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
index b33074b783dc..c734987a344c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c
@@ -719,6 +719,10 @@ static void mt76x0_phy_set_gain_val(struct mt76x02_dev
*dev)
mt76_wr(dev, MT_BBP(AGC, 8),
val | FIELD_PREP(MT_BBP_AGC_GAIN, gain));
+
+ if ((dev->mt76.chandef.chan->flags & IEEE80211_CHAN_RADAR) &&
+ !is_mt7630(dev))
+ mt76x02_phy_dfs_adjust_agc(dev);
}
static void
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c
b/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c
index 21e7b8c9f824..527e530d480a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c
@@ -802,6 +802,35 @@ static void mt76x02_dfs_set_bbp_params(struct mt76x02_dev
*dev)
mt76_wr(dev, 0x212c, 0x0c350001);
}
+void mt76x02_phy_dfs_adjust_agc(struct mt76x02_dev *dev)
+{
+ u32 agc_r8, agc_r4, val_r8, val_r4, dfs_r31;
+
+ agc_r8 = mt76_rr(dev, MT_BBP(AGC, 8));
+ agc_r4 = mt76_rr(dev, MT_BBP(AGC, 4));
+
+ val_r8 = (agc_r8 & 0x7e00) >> 9;
+ val_r4 = agc_r4 & ~0x1f00;
+ val_r4 += (((val_r8 + 1) >> 1) << 24);
+ mt76_wr(dev, MT_BBP(AGC, 4), val_r4);
+
+ dfs_r31 = FIELD_GET(MT_BBP_AGC_LNA_HIGH_GAIN, val_r4);
+ dfs_r31 += val_r8;
+ dfs_r31 -= (agc_r8 & 0x0038) >> 3;
+ dfs_r31 = (dfs_r31 << 16) | 0x0307;
+ mt76_wr(dev, MT_BBP(DFS, 31), dfs_r31);
+
+ if (is_mt76x2(dev)) {
+ mt76_wr(dev, MT_BBP(DFS, 32), 0x00040071);
+ } else {
+ /* disable hw detector */
+ mt76_wr(dev, MT_BBP(DFS, 0), 0);
+ /* enable hw detector */
+ mt76_wr(dev, MT_BBP(DFS, 0), MT_DFS_CH_EN << 16);
+ }
+}
+EXPORT_SYMBOL_GPL(mt76x02_phy_dfs_adjust_agc);
+
void mt76x02_dfs_init_params(struct mt76x02_dev *dev)
{
struct cfg80211_chan_def *chandef = >mt76.chandef;
@@ -841,7 +870,6 @@ void mt76x02_dfs_init_detector(struct mt76x02_dev *dev)
tasklet_init(_pd->dfs_tasklet, mt76x02_dfs_tasklet,
(unsigned long)dev);
}
-EXPORT_SYMBOL_GPL(mt76x02_dfs_init_detector);
static void
mt76x02_dfs_set_domain(struct mt76x02_dev *dev,
@@ -865,4 +893,3 @@ void mt76x02_regd_notifier(struct wiphy *wiphy,
mt76x02_dfs_set_domain(dev, request->dfs_region);
}
-EXPORT_SYMBOL_GPL(mt76x02_regd_notifier);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.h
b/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.h
index 59e1524ff98b..70b394e17340 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.h
@@ -141,4 +141,5 @@ void mt76x02_dfs_init_params(struct mt76x02_dev *dev);
void mt76x02_dfs_init_detector(struct mt76x02_dev *dev);
void mt76x02_regd_notifier(struct wiphy *wiphy,
struct regulatory_request *request);
+void mt76x02_phy_dfs_adjust_agc(struct mt76x02_dev *dev);
#endif /* __MT76x02_DFS_H */
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
[PATCH 1/2] mt76: move dfs support in mt76x02-lib module
Move mt76x2 DFS support in mt76x02-lib module in order to
be reused by mt76x0 driver and unlock DFS frequencies
Signed-off-by: Lorenzo Bianconi
---
drivers/net/wireless/mediatek/mt76/Makefile | 3 +-
.../mt76/{mt76x2/pci_dfs.c => mt76x02_dfs.c} | 135 ++
.../net/wireless/mediatek/mt76/mt76x02_dfs.h | 4 +
.../wireless/mediatek/mt76/mt76x2/Makefile| 2 +-
.../net/wireless/mediatek/mt76/mt76x2/dfs.h | 25
.../wireless/mediatek/mt76/mt76x2/mt76x2.h| 1 -
.../wireless/mediatek/mt76/mt76x2/pci_init.c | 13 +-
.../wireless/mediatek/mt76/mt76x2/pci_main.c | 2 +-
8 files changed, 83 insertions(+), 102 deletions(-)
rename drivers/net/wireless/mediatek/mt76/{mt76x2/pci_dfs.c => mt76x02_dfs.c}
(86%)
delete mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2/dfs.h
diff --git a/drivers/net/wireless/mediatek/mt76/Makefile
b/drivers/net/wireless/mediatek/mt76/Makefile
index a737a518802f..1a45cb30f39f 100644
--- a/drivers/net/wireless/mediatek/mt76/Makefile
+++ b/drivers/net/wireless/mediatek/mt76/Makefile
@@ -14,7 +14,8 @@ CFLAGS_mt76x02_trace.o := -I$(src)
mt76x02-lib-y := mt76x02_util.o mt76x02_mac.o mt76x02_mcu.o \
mt76x02_eeprom.o mt76x02_phy.o mt76x02_mmio.o \
-mt76x02_txrx.o mt76x02_trace.o mt76x02_debugfs.o
+mt76x02_txrx.o mt76x02_trace.o mt76x02_debugfs.o \
+mt76x02_dfs.o
mt76x02-usb-y := mt76x02_usb_mcu.o mt76x02_usb_core.o
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_dfs.c
b/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c
similarity index 86%
rename from drivers/net/wireless/mediatek/mt76/mt76x2/pci_dfs.c
rename to drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c
index 8d66952400a8..21e7b8c9f824 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_dfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c
@@ -14,7 +14,7 @@
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
-#include "mt76x2.h"
+#include "mt76x02.h"
#define RADAR_SPEC(m, len, el, eh, wl, wh, \
w_tolerance, tl, th, t_tolerance,\
@@ -151,8 +151,7 @@ static const struct mt76x02_radar_specs
jp_w53_radar_specs[] = {
};
static void
-mt76x2_dfs_set_capture_mode_ctrl(struct mt76x02_dev *dev,
-u8 enable)
+mt76x02_dfs_set_capture_mode_ctrl(struct mt76x02_dev *dev, u8 enable)
{
u32 data;
@@ -160,8 +159,8 @@ mt76x2_dfs_set_capture_mode_ctrl(struct mt76x02_dev *dev,
mt76_wr(dev, MT_BBP(DFS, 36), data);
}
-static void mt76x2_dfs_seq_pool_put(struct mt76x02_dev *dev,
- struct mt76x02_dfs_sequence *seq)
+static void mt76x02_dfs_seq_pool_put(struct mt76x02_dev *dev,
+struct mt76x02_dfs_sequence *seq)
{
struct mt76x02_dfs_pattern_detector *dfs_pd = >dfs_pd;
@@ -172,7 +171,7 @@ static void mt76x2_dfs_seq_pool_put(struct mt76x02_dev *dev,
}
static struct mt76x02_dfs_sequence *
-mt76x2_dfs_seq_pool_get(struct mt76x02_dev *dev)
+mt76x02_dfs_seq_pool_get(struct mt76x02_dev *dev)
{
struct mt76x02_dfs_pattern_detector *dfs_pd = >dfs_pd;
struct mt76x02_dfs_sequence *seq;
@@ -192,7 +191,7 @@ mt76x2_dfs_seq_pool_get(struct mt76x02_dev *dev)
return seq;
}
-static int mt76x2_dfs_get_multiple(int val, int frac, int margin)
+static int mt76x02_dfs_get_multiple(int val, int frac, int margin)
{
int remainder, factor;
@@ -214,7 +213,7 @@ static int mt76x2_dfs_get_multiple(int val, int frac, int
margin)
return factor;
}
-static void mt76x2_dfs_detector_reset(struct mt76x02_dev *dev)
+static void mt76x02_dfs_detector_reset(struct mt76x02_dev *dev)
{
struct mt76x02_dfs_pattern_detector *dfs_pd = >dfs_pd;
struct mt76x02_dfs_sequence *seq, *tmp_seq;
@@ -231,11 +230,11 @@ static void mt76x2_dfs_detector_reset(struct mt76x02_dev
*dev)
list_for_each_entry_safe(seq, tmp_seq, _pd->sequences, head) {
list_del_init(>head);
- mt76x2_dfs_seq_pool_put(dev, seq);
+ mt76x02_dfs_seq_pool_put(dev, seq);
}
}
-static bool mt76x2_dfs_check_chirp(struct mt76x02_dev *dev)
+static bool mt76x02_dfs_check_chirp(struct mt76x02_dev *dev)
{
bool ret = false;
u32 current_ts, delta_ts;
@@ -256,8 +255,8 @@ static bool mt76x2_dfs_check_chirp(struct mt76x02_dev *dev)
return ret;
}
-static void mt76x2_dfs_get_hw_pulse(struct mt76x02_dev *dev,
- struct mt76x02_dfs_hw_pulse *pulse)
+static void mt76x02_dfs_get_hw_pulse(struct mt76x02_dev *dev,
+struct mt76x02_dfs_hw_pulse *pulse)
{
u32 data;
@@ -276,8 +275,8 @@ static void mt76x2_dfs_get_hw_pulse(struct mt76x02_dev *dev,
pulse->burst = mt76_rr(dev, MT_BBP(DFS, 22));
}
-static bool mt76x2_dfs_check_hw_pulse(struct mt76x02_dev *dev,
-
[PATCH 0/2] add dfs support to mt76x0e driver
Introduce {sw,hw} dfs detector to mt76x0e driver in order to
properly unlock radar frequencies
This series is based on top of 'unify drv_bss_info_changed
between mt76x0 and mt76x2' one:
https://patchwork.kernel.org/cover/10650357/
Lorenzo Bianconi (2):
mt76: move dfs support in mt76x02-lib module
mt76x0: pci: add DFS support
drivers/net/wireless/mediatek/mt76/Makefile | 3 +-
.../net/wireless/mediatek/mt76/mt76x0/main.c | 11 +-
.../net/wireless/mediatek/mt76/mt76x0/phy.c | 4 +
.../mt76/{mt76x2/pci_dfs.c => mt76x02_dfs.c} | 162 +++---
.../net/wireless/mediatek/mt76/mt76x02_dfs.h | 5 +
.../net/wireless/mediatek/mt76/mt76x02_util.c | 5 +
.../wireless/mediatek/mt76/mt76x2/Makefile| 2 +-
.../net/wireless/mediatek/mt76/mt76x2/dfs.h | 25 ---
.../wireless/mediatek/mt76/mt76x2/mt76x2.h| 1 -
.../wireless/mediatek/mt76/mt76x2/pci_init.c | 16 --
.../wireless/mediatek/mt76/mt76x2/pci_main.c | 2 +-
.../net/wireless/mediatek/mt76/mt76x2/phy.c | 23 +--
12 files changed, 128 insertions(+), 131 deletions(-)
rename drivers/net/wireless/mediatek/mt76/{mt76x2/pci_dfs.c => mt76x02_dfs.c}
(83%)
delete mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2/dfs.h
--
2.19.1
Should we check netif_running in cfg80211_calculate_bi_data?
I was testing on my 4.16 kernel with a bunch of VAPs and I had two configured for 100 beacon interval, and more at 240. This failed for reasons I figured out (gcd logic), but even once I tried to configure the vaps for 240 interval they could not come up. I am thinking maybe it was because I could only re-configure admin-up interfaces, and they couldn't come up due the gcd thing? Anyway, while poking, I thought maybe the patch below would be helpful since we shouldn't care about admin-down interfaces in this case? diff --git a/net/wireless/util.c b/net/wireless/util.c index fbc880e..56d7583 100644 --- a/net/wireless/util.c +++ b/net/wireless/util.c @@ -1541,6 +1541,9 @@ static void cfg80211_calculate_bi_data(struct wiphy *wiphy, u32 new_beacon_int, if (wdev->beacon_interval == *beacon_int_gcd) continue; + if (!netif_running(wdev->netdev)) + continue; + *beacon_int_different = true; *beacon_int_gcd = gcd(*beacon_int_gcd, wdev->beacon_interval); } Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: [PATCH v6 1/2] cfg80211: add peer measurement with FTM initiator API
On 10/17/2018 3:37 PM, Johannes Berg wrote: [...] Looks mostly good to me, some minor comments below... > +/** > + * struct cfg80211_pmsr_ftm_result - FTM result > + * @failure_reason: if this measurement failed (PMSR status is > + * %NL80211_PMSR_STATUS_FAILURE), this gives a more precise > + * reason than just "failure" > + * @burst_index: if reporting partial results, this is the index > + * in [0 .. num_bursts-1] of the burst that's being reported > + * @num_ftmr_attempts: number of FTM request frames transmitted > + * @num_ftmr_successes: number of FTM request frames acked > + * @busy_retry_time: if failure_reason is > %NL80211_PMSR_FTM_FAILURE_PEER_BUSY, > + * fill this to indicate in how many seconds a retry is deemed possible > + * by the responder > + * @num_bursts_exp: actual number of bursts exponent negotiated > + * @burst_duration: actual burst duration negotiated > + * @ftms_per_burst: actual frames per burst negotiated actual frames -> actual ftms > +/** > + * struct cfg80211_pmsr_ftm_request_peer - FTM request data > + * @requested: indicates FTM is requested > + * @preamble: frame preamble to use > + * @burst_period: burst period to use > + * @asap: indicates to use ASAP mode > + * @num_bursts_exp: number of bursts exponent > + * @burst_duration: burst duration > + * @ftms_per_burst: number of frames per burst frames -> ftms > > +/** > + * struct cfg80211_pmsr_capabilities - cfg80211 peer measurement capabilities > + * @max_peers: maximum number of peers in a single measurement > + * @report_ap_tsf: can report assoc AP's TSF for radio resource measurement > + * @randomize_mac_addr: can randomize MAC address for measurement > + * @ftm.supported: FTM measurement is supported > + * @ftm.asap: ASAP-mode is supported > + * @ftm.non_asap: non-ASAP-mode is supported > + * @ftm.request_lci: can request LCI data > + * @ftm.request_civicloc: can request civic location data > + * @ftm.preambles: bitmap of preambles supported ( nl80211_preamble) > + * @ftm.bandwidths: bitmap of bandwidths supported ( nl80211_chan_width) > + * @ftm.max_bursts_exponent: maximum burst exponent supported > + * (set to 0 if not limited; note that setting this will necessarily > + * forbid using the value 15 to let the responder pick) How can driver specify it only supports a single burst? (This is what our internal wil6210 implementation currently supports...) Thanks, Lior
Re: Where to report mpdus tx vs failed?
On 10/22/2018 05:07 AM, Johannes Berg wrote:
On Mon, 2018-10-22 at 14:06 +0200, Johannes Berg wrote:
On Fri, 2018-10-19 at 11:32 -0700, Ben Greear wrote:
I was hoping I could fit it into some existing stat. It is sort of like
retries, so that will be my first attempt.
By investigating an RF sniff, I notice the 9880 ath10k (with my fw
and driver, at least), will retransmit about 30% of the frames when running
at least one of my test cases (small udp frame transmit to AP that can only do
about mcs5 or mcs7
reliably at 3x3 nss).
I'd like to report this stat in my wifi test tool if nothing else, but
likely other people would make use of it as well.
We have NL80211_STA_INFO_TX_RETRIES, shouldn't you be able to capture it
there?
Or, per TID, NL80211_TID_STATS_TX_MSDU_RETRIES
I added this code (rate is struct ieee80211_tx_rate)
if (tx_done->mpdus_failed) {
/* Maybe there is a better way to report this tried vs failed
stat up the stack? */
rate->count = tx_done->mpdus_failed + 1;
}
else {
rate->count = 1;
}
I think this is mostly providing useful info up the stack and we are trying to
verify
the counts against a packet sniff today. The driver is only reporting
this number for the first packet in the ampdu chain, so all retries are counted
against the
first frame (the rest will have mpdus_failed == 0 regardless of how many
retries they have).
And, on total retry failure, packets should be reported up the stack as
tx-no-ack, so I think
that is working OK too.
I guess mac80211 could use this tx-status to report per-tid if it cared to. I
don't see any
other way to pass such tx failure details up the stack to mac80211.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
Re: Where to report mpdus tx vs failed?
On Mon, 2018-10-22 at 14:06 +0200, Johannes Berg wrote: > On Fri, 2018-10-19 at 11:32 -0700, Ben Greear wrote: > > > > I was hoping I could fit it into some existing stat. It is sort of like > > retries, so that will be my first attempt. > > > > By investigating an RF sniff, I notice the 9880 ath10k (with my fw > > and driver, at least), will retransmit about 30% of the frames when running > > at least one of my test cases (small udp frame transmit to AP that can only > > do about mcs5 or mcs7 > > reliably at 3x3 nss). > > > > I'd like to report this stat in my wifi test tool if nothing else, but > > likely other people would make use of it as well. > > > We have NL80211_STA_INFO_TX_RETRIES, shouldn't you be able to capture it > there? Or, per TID, NL80211_TID_STATS_TX_MSDU_RETRIES johannes
Re: Where to report mpdus tx vs failed?
On Fri, 2018-10-19 at 11:32 -0700, Ben Greear wrote: > > I was hoping I could fit it into some existing stat. It is sort of like > retries, so that will be my first attempt. > > By investigating an RF sniff, I notice the 9880 ath10k (with my fw > and driver, at least), will retransmit about 30% of the frames when running > at least one of my test cases (small udp frame transmit to AP that can only > do about mcs5 or mcs7 > reliably at 3x3 nss). > > I'd like to report this stat in my wifi test tool if nothing else, but > likely other people would make use of it as well. We have NL80211_STA_INFO_TX_RETRIES, shouldn't you be able to capture it there? johannes
Re: 4.18.16: memory leak in sta_set_sinfo
On 10/22/2018 10:37 AM, Johannes Berg wrote: On Mon, 2018-10-22 at 10:35 +0200, Johannes Stezenbach wrote: commit 848e616e66d4592fe9afc40743d3504deb7632b4 Author: Stefan Seyfried Date: Sun Sep 30 12:53:00 2018 +0200 cfg80211: fix wext-compat memory leak Hopefully that'll eventually propagate to stable. Good to know it's fixed, but "hopefully" makes me wonder, I'd love to hear the confirmation that it's been queued. Well, normally it works automatically when you have a Fixes tag, so I don't usually try to queue anything manually. Maybe Greg has had his hands full with the 4.19 release :-) Missed the memo. Does that mean Cc: to stable is no longer needed? It is still documented as such in Documentation/process/stable-kernel-rules.rst. Regards, Arend
Re: 4.18.16: memory leak in sta_set_sinfo
On Mon, 2018-10-22 at 10:35 +0200, Johannes Stezenbach wrote: > > commit 848e616e66d4592fe9afc40743d3504deb7632b4 > > Author: Stefan Seyfried > > Date: Sun Sep 30 12:53:00 2018 +0200 > > > > cfg80211: fix wext-compat memory leak > > > > Hopefully that'll eventually propagate to stable. > > Good to know it's fixed, but "hopefully" makes me wonder, > I'd love to hear the confirmation that it's been queued. Well, normally it works automatically when you have a Fixes tag, so I don't usually try to queue anything manually. Maybe Greg has had his hands full with the 4.19 release :-) johannes
Re: 4.18.16: memory leak in sta_set_sinfo
On Mon, Oct 22, 2018 at 10:25:07AM +0200, Johannes Berg wrote: > On Mon, 2018-10-22 at 10:02 +0200, Johannes Stezenbach wrote: > > > > [] sta_set_sinfo+0x634/0x900 [mac80211] > > [ ] ieee80211_get_station+0x50/0x70 [mac80211] > > [<9fd8a7aa>] cfg80211_wext_giwrate+0x111/0x2b0 [cfg80211] > > > I guess it relates to > > 0fdf1493b41 " mac80211: allocate and fill tidstats only when needed" > > which Fixes: 8689c051a201 ("cfg80211: dynamically allocate per-tid stats > > for station info") > > Yes, you're using wext which we don't any more, so we didn't see this. Yes, disappointing that conky still uses wext. > However, it's already fixed: > > commit 848e616e66d4592fe9afc40743d3504deb7632b4 > Author: Stefan Seyfried > Date: Sun Sep 30 12:53:00 2018 +0200 > > cfg80211: fix wext-compat memory leak > > Hopefully that'll eventually propagate to stable. Good to know it's fixed, but "hopefully" makes me wonder, I'd love to hear the confirmation that it's been queued. OTOH I'll apply the patch locally and eventually move to 4.19, so what gives... Thanks, Johannes
Re: 4.18.16: memory leak in sta_set_sinfo
On Mon, 2018-10-22 at 10:02 +0200, Johannes Stezenbach wrote: > > [] sta_set_sinfo+0x634/0x900 [mac80211] > [ ] ieee80211_get_station+0x50/0x70 [mac80211] > [<9fd8a7aa>] cfg80211_wext_giwrate+0x111/0x2b0 [cfg80211] > I guess it relates to > 0fdf1493b41 " mac80211: allocate and fill tidstats only when needed" > which Fixes: 8689c051a201 ("cfg80211: dynamically allocate per-tid stats for > station info") Yes, you're using wext which we don't any more, so we didn't see this. However, it's already fixed: commit 848e616e66d4592fe9afc40743d3504deb7632b4 Author: Stefan Seyfried Date: Sun Sep 30 12:53:00 2018 +0200 cfg80211: fix wext-compat memory leak Hopefully that'll eventually propagate to stable. johannes
4.18.16: memory leak in sta_set_sinfo
Hi, I used 4.18.11 for a while and noticed a memleak showing in slabtop as kmalloc-2048. Then I updated to 4.18.16 and enabled kmemleak, it dumps this: unreferenced object 0xa10a5cc49800 (size 2048): comm "conky", pid 2734, jiffies 4295635396 (age 454.650s) hex dump (first 32 bytes): 1e 00 00 00 00 00 00 00 ad 13 00 00 00 00 00 00 a1 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [] sta_set_sinfo+0x634/0x900 [mac80211] [ ] ieee80211_get_station+0x50/0x70 [mac80211] [<39cfbb15>] cfg80211_wireless_stats+0x103/0x350 [cfg80211] [<3e9c0192>] iw_handler_get_iwstats+0x3b/0x90 [<58160332>] ioctl_standard_iw_point+0xef/0x370 [<8af7fc78>] ioctl_standard_call+0x9d/0xb0 [<9ad7a410>] wext_handle_ioctl+0x99/0xf0 [<6bc483dc>] sock_ioctl+0x1b5/0x330 [<4a40c83b>] do_vfs_ioctl+0xa4/0x620 [ ] ksys_ioctl+0x3a/0x70 [<033ccded>] __x64_sys_ioctl+0x16/0x20 [<38d98ffe>] do_syscall_64+0x56/0x110 [<913ebc09>] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ ] 0x unreferenced object 0xa10a5cc4c000 (size 2048): comm "conky", pid 2734, jiffies 4295635396 (age 454.650s) hex dump (first 32 bytes): 1e 00 00 00 00 00 00 00 ad 13 00 00 00 00 00 00 a1 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [ ] sta_set_sinfo+0x634/0x900 [mac80211] [ ] ieee80211_get_station+0x50/0x70 [mac80211] [<9fd8a7aa>] cfg80211_wext_giwrate+0x111/0x2b0 [cfg80211] [<45f8e84f>] ioctl_standard_call+0x4d/0xb0 [<9ad7a410>] wext_handle_ioctl+0x99/0xf0 [<6bc483dc>] sock_ioctl+0x1b5/0x330 [<4a40c83b>] do_vfs_ioctl+0xa4/0x620 [ ] ksys_ioctl+0x3a/0x70 [<033ccded>] __x64_sys_ioctl+0x16/0x20 [<38d98ffe>] do_syscall_64+0x56/0x110 [<913ebc09>] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ ] 0x etc. sta_set_sinfo+0x634/0x900 seemt to be the call to cfg80211_sinfo_alloc_tid_stats(). dmesg: [ 2975.537043] kmemleak: 1223 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [ 3140.960503] kmemleak: 851 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [ 3755.462385] kmemleak: 280 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [ 4369.876913] kmemleak: 1011 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [ 4984.711904] kmemleak: 1002 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [ 5598.838136] kmemleak: 1023 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [ 6213.236272] kmemleak: 1088 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [ 6833.692160] kmemleak: 1004 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [ 7447.151259] kmemleak: 1147 new suspected memory leaks (see /sys/kernel/debug/kmemleak) I guess it relates to 0fdf1493b41 " mac80211: allocate and fill tidstats only when needed" which Fixes: 8689c051a201 ("cfg80211: dynamically allocate per-tid stats for station info") Johannes
RE: Rate-ctrl experience gained with ath10k
Hi Ben, Just a quick reaction: I guess the choice should mainly depend on the mean airtime to transmit a frame, not on the final throughput, since it is a shared half-duplex media? Retransmission is fine up to the point it does not take more airtime than a lower MCS? Jean-Pierre > -Message d'origine- > De : linux-wireless-ow...@vger.kernel.org > [mailto:linux-wireless-ow...@vger.kernel.org] De la part de > Ben Greear > Envoyé : samedi 20 octobre 2018 20:57 > À : linux-wireless@vger.kernel.org > Objet : Re: Rate-ctrl experience gained with ath10k > > I now have the 9984 ath10k working pretty good I think, at least as far as > rate-ctrl is going. It tries to keep retransmit < 10% and throughput is > fine compared to using MCS with higher retransmit (and higher encoding rates). > > But, I tried to put similar changes (dodge high retransmit MCS if possible), > and for the wave-1 9880 chip, this decreased throughput. > > For instance, current rate-ctrl was retransmitting about 30% of the frames > when allowed to choose its MCS. In this case, I saw around 225-230Mbps > throughput. > > But, if I forced it down to MCS-5, 3x3, then throughput was about 220Mbps, and > retry percent was closer to 2%. > > So, question is...should I still tweak its ratectrl to choose lower MCS when > retransmit % is high, or should I just let it retransmit. Maybe lower MCS > and lower > retransmit would be better over-all if there are lots of devices on the > network? > > I'll run some tests to experiment with that when I have time, but curious if > others > have already done similar... > > Thanks, > Ben > > > On 10/16/2018 04:31 PM, Ben Greear wrote: > > So, I've been trying to understand why the ath10k-rate ctrl was acting > > so poorly in my 20-station UDP tx case. I wrote that wifi-diag tool, > > and it gave some clues, but only in retrospect were they obvious :) > > > > The problem in general was that a single station could upload, at say > > 500Mbps, > > but 20 stations could only do about 325Mbps. If we fixed the MCS at 3x3 > > MCS7, > > then the 20 station upload test ran about 490Mbps. > > > > There were several optimizations I made in the ath10k firmware rate-ctrl. > > One > > was to penalize rates with higher PER (packet error rate) more than the old > > algorithm did. This > helped > > a small bit, but not enough (around 350-370Mbps total throughput). > > > > Then, after adding logs I noticed that each station was probing once about > > every 5 ampdu > > chains, or almost 20% of the time! These probe AMPDUs are limited to a max > > of 4 AMSDUs, > > and that explains why my 'bad' case showed 17% of the AMPDU chains were 4 > > in length in > > my wifi-diag output. > > > > I changed the firmware to take number of active stations into account, and > > increase the > > 75ms probe interval by up to a factor of 5. I also probe less often when > > the probed > > rate has PER > 5 or the last probe had a dropped frame. > > > > And, I allow probing with AMPDU chains of up to 16 AMSDU instead of just 4. > > > > Together this gets me up to about 460Mbps in this test case. Still not > > quite as good > > as fixing the MCS at 7, but good enough I think. > > > > Here's hoping this email will let other folks poking at rate-ctrl have a > > faster > > time at fixing things than I did. > > > > Thanks, > > Ben > > > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com
