* Re: [RFC V2 0/8] nl80211: add 6GHz band support
From: Johannes Berg @ 2019-07-24 13:46 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless
In-Reply-To: <16c243667a8.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
On Wed, 2019-07-24 at 15:40 +0200, Arend Van Spriel wrote:
>
> > > The only place I could find an
> > > issue with this is in cfg80211_wext_freq(). Not sure how to deal with
> > > that so it is not part of this series.
> >
> > Just finally break wext and say if you want to use 6 GHz you need to use
> > nl80211? :)
>
> Probably is true for he support as well. Not sure. Have not been using wext
> for the last decade ;-)
Me neither, our official releases don't even support it.
Btw, there's a compiler warning introduced by the first patch, I think
the fix is trivial though to add the 6GHZ in one place in mac80211
already.
johannes
^ permalink raw reply
* Re: [RFC V2 0/8] nl80211: add 6GHz band support
From: Arend Van Spriel @ 2019-07-24 13:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <fbacce3dd78c2154ee21c4f26f76a18a18349f45.camel@sipsolutions.net>
On July 24, 2019 11:35:14 AM Johannes Berg <johannes@sipsolutions.net> wrote:
> Hi Arend,
>
>
>
>
> After all the discussion, I think we want this?
I think so yes. Even if it is just informational for user-space it seems to
make sense for kernel side.
> Care to resend?
Will do.
> I think I want it at least because we shouldn't advertise HT/VHT on 6
> GHz as is (just as part of HE) and that's easier if we have a different
> band enum, for the capability storage...
Right.
>
>> The only place I could find an
>> issue with this is in cfg80211_wext_freq(). Not sure how to deal with
>> that so it is not part of this series.
>
> Just finally break wext and say if you want to use 6 GHz you need to use
> nl80211? :)
Probably is true for he support as well. Not sure. Have not been using wext
for the last decade ;-)
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 1/2] net: mac80211: Fix possible null-pointer dereferences in ieee80211_setup_sdata()
From: Johannes Berg @ 2019-07-24 12:40 UTC (permalink / raw)
To: Jia-Ju Bai, davem; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20190724123623.10093-1-baijiaju1990@gmail.com>
On Wed, 2019-07-24 at 20:36 +0800, Jia-Ju Bai wrote:
> In ieee80211_setup_sdata(), there is an if statement on line 1410 to
> check whether sdata->dev is NULL:
> if (sdata->dev)
>
> When sdata->dev is NULL, it is used on lines 1458 and 1459:
> sdata->dev->type = ARPHRD_IEEE80211_RADIOTAP;
> sdata->dev->netdev_ops = &ieee80211_monitorif_ops;
>
> Thus, possible null-pointer dereferences may occur.
No, this cannot happen, monitor interfaces (NL80211_IFTYPE_MONITOR) must
have a valid ->dev, only P2P device and NAN might not.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] net: mac80211: Fix possible null-pointer dereferences in ieee80211_xmit_fast_finish()
From: Johannes Berg @ 2019-07-24 12:39 UTC (permalink / raw)
To: Jia-Ju Bai, davem; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20190724123633.10145-1-baijiaju1990@gmail.com>
On Wed, 2019-07-24 at 20:36 +0800, Jia-Ju Bai wrote:
> In ieee80211_xmit_fast_finish(), there is an if statement on line 3356
> to check whether key is NULL:
> if (key)
>
> When key is NULL, it is used on line 3388:
> switch (key->conf.cipher)
> and line 3393:
> pn = atomic64_inc_return(&key->conf.tx_pn);
> and line 3396:
> crypto_hdr[3] = 0x20 | (key->conf.keyidx << 6);
>
> Thus, possible null-pointer dereferences may occur.
No, this cannot happen, because pn_offs can only be non-zero when there
is a key. Maybe we should pass the fast_tx pointer instead of the
pn_offs/key from it, but the two are coupled.
johannes
^ permalink raw reply
* [PATCH 2/2] net: mac80211: Fix possible null-pointer dereferences in ieee80211_xmit_fast_finish()
From: Jia-Ju Bai @ 2019-07-24 12:36 UTC (permalink / raw)
To: johannes, davem; +Cc: linux-wireless, netdev, linux-kernel, Jia-Ju Bai
In ieee80211_xmit_fast_finish(), there is an if statement on line 3356
to check whether key is NULL:
if (key)
When key is NULL, it is used on line 3388:
switch (key->conf.cipher)
and line 3393:
pn = atomic64_inc_return(&key->conf.tx_pn);
and line 3396:
crypto_hdr[3] = 0x20 | (key->conf.keyidx << 6);
Thus, possible null-pointer dereferences may occur.
To fix these bugs, key is checked on line 3384.
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/mac80211/tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index f13eb2f61ccf..2cc261165b91 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3381,7 +3381,7 @@ static void ieee80211_xmit_fast_finish(struct ieee80211_sub_if_data *sdata,
sta->tx_stats.bytes[skb_get_queue_mapping(skb)] += skb->len;
sta->tx_stats.packets[skb_get_queue_mapping(skb)]++;
- if (pn_offs) {
+ if (key && pn_offs) {
u64 pn;
u8 *crypto_hdr = skb->data + pn_offs;
--
2.17.0
^ permalink raw reply related
* [PATCH 1/2] net: mac80211: Fix possible null-pointer dereferences in ieee80211_setup_sdata()
From: Jia-Ju Bai @ 2019-07-24 12:36 UTC (permalink / raw)
To: johannes, davem; +Cc: linux-wireless, netdev, linux-kernel, Jia-Ju Bai
In ieee80211_setup_sdata(), there is an if statement on line 1410 to
check whether sdata->dev is NULL:
if (sdata->dev)
When sdata->dev is NULL, it is used on lines 1458 and 1459:
sdata->dev->type = ARPHRD_IEEE80211_RADIOTAP;
sdata->dev->netdev_ops = &ieee80211_monitorif_ops;
Thus, possible null-pointer dereferences may occur.
To fix these bugs, sdata->dev is checked before being used.
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
net/mac80211/iface.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 06aac0aaae64..e49264981a7b 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1455,8 +1455,10 @@ static void ieee80211_setup_sdata(struct ieee80211_sub_if_data *sdata,
ieee80211_mesh_init_sdata(sdata);
break;
case NL80211_IFTYPE_MONITOR:
- sdata->dev->type = ARPHRD_IEEE80211_RADIOTAP;
- sdata->dev->netdev_ops = &ieee80211_monitorif_ops;
+ if (sdata->dev) {
+ sdata->dev->type = ARPHRD_IEEE80211_RADIOTAP;
+ sdata->dev->netdev_ops = &ieee80211_monitorif_ops;
+ }
sdata->u.mntr.flags = MONITOR_FLAG_CONTROL |
MONITOR_FLAG_OTHER_BSS;
break;
--
2.17.0
^ permalink raw reply related
* Re: [PATCH] ath10k: add mic bytes for pmf management packet
From: Kalle Valo @ 2019-07-24 12:10 UTC (permalink / raw)
To: Wen Gong
Cc: Ben Greear, Wen Gong, ath10k@lists.infradead.org,
linux-wireless@vger.kernel.org
In-Reply-To: <9403fef58374427fa76fb32ee64ee333@aptaiexm02f.ap.qualcomm.com>
Wen Gong <wgong@qti.qualcomm.com> writes:
>> -----Original Message-----
>> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Ben
>> Greear
>> Sent: Tuesday, June 18, 2019 12:04 AM
>> To: Wen Gong <wgong@codeaurora.org>; ath10k@lists.infradead.org
>> Cc: linux-wireless@vger.kernel.org
>> Subject: [EXT] Re: [PATCH] ath10k: add mic bytes for pmf management
>> packet
>>
>> I was looking at mac80211 code recently, and it seems some action
>> frames are NOT supposed to be protected. I added my own helper
>> method to my local ath10k. Maybe you want to use this?
>>
>>
>> /* Copied from ieee80211_is_robust_mgmt_frame, but disable the check for
>> has_protected
>> * since we do tx hw crypt, and it won't actually be encrypted even when this
>> flag is
>> * set.
>> */
>> bool ieee80211_is_robust_mgmt_frame_tx(struct ieee80211_hdr *hdr)
>> {
>> if (ieee80211_is_disassoc(hdr->frame_control) ||
>> ieee80211_is_deauth(hdr->frame_control))
>> return true;
>>
>> if (ieee80211_is_action(hdr->frame_control)) {
>> u8 *category;
>>
>> /*
>> * Action frames, excluding Public Action frames, are Robust
>> * Management Frames. However, if we are looking at a Protected
>> * frame, skip the check since the data may be encrypted and
>> * the frame has already been found to be a Robust Management
>> * Frame (by the other end).
>> */
>> /*
>> if (ieee80211_has_protected(hdr->frame_control))
>> return true;
>> */
>> category = ((u8 *) hdr) + 24;
>> return *category != WLAN_CATEGORY_PUBLIC &&
>> *category != WLAN_CATEGORY_HT &&
>> *category != WLAN_CATEGORY_WNM_UNPROTECTED &&
>> *category != WLAN_CATEGORY_SELF_PROTECTED &&
>> *category != WLAN_CATEGORY_UNPROT_DMG &&
>> *category != WLAN_CATEGORY_VHT &&
>> *category != WLAN_CATEGORY_VENDOR_SPECIFIC;
>> }
>>
>> return false;
>> }
>>
>> Thanks,
>> Ben
>>
>> > +
>> > data_len = msdu->len;
>> >
>> > switch (txmode) {
>> >
>>
>>
> Thanks Ben,
>
> seems the ieee80211_is_robust_mgmt_frame_tx is not
> match my change.
So what's the conclusion, can I take this patch?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH net-next 00/10] Use dev_get_drvdata where possible
From: Kalle Valo @ 2019-07-24 11:57 UTC (permalink / raw)
To: Chuhong Yuan
Cc: Mirko Lindner, Stephen Hemminger, Jiri Slaby, Nick Kossifidis,
Luis Chamberlain, Stanislaw Gruszka, QCA ath9k Development,
Maya Erez, Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Ping-Ke Shih,
Intel Linux Wireless, David S . Miller,
Solarflare linux maintainers, Edward Cree, Mart in Habets, netdev,
wil6210, linux-wireless, linux-kernel
In-Reply-To: <20190724112524.13042-1-hslester96@gmail.com>
Chuhong Yuan <hslester96@gmail.com> writes:
> These patches use dev_get_drvdata instead of
> using to_pci_dev + pci_get_drvdata to make
> code simpler.
>
> Chuhong Yuan (10):
> net: marvell: Use dev_get_drvdata where possible
> forcedeth: Use dev_get_drvdata where possible
> sfc: Use dev_get_drvdata where possible
> sfc-falcon: Use dev_get_drvdata where possible
> ath: Use dev_get_drvdata where possible
> iwlegacy: Use dev_get_drvdata where possible
> iwlwifi: Use dev_get_drvdata where possible
> mwifiex: pcie: Use dev_get_drvdata
> qtnfmac_pcie: Use dev_get_drvdata
> rtlwifi: rtl_pci: Use dev_get_drvdata
>
> drivers/net/ethernet/marvell/skge.c | 6 ++----
> drivers/net/ethernet/marvell/sky2.c | 3 +--
> drivers/net/ethernet/nvidia/forcedeth.c | 3 +--
> drivers/net/ethernet/sfc/ef10.c | 4 ++--
> drivers/net/ethernet/sfc/efx.c | 10 +++++-----
> drivers/net/ethernet/sfc/falcon/efx.c | 6 +++---
> drivers/net/ethernet/sfc/falcon/falcon_boards.c | 4 ++--
> drivers/net/wireless/ath/ath5k/pci.c | 3 +--
> drivers/net/wireless/ath/ath9k/pci.c | 5 ++---
> drivers/net/wireless/ath/wil6210/pcie_bus.c | 6 ++----
> drivers/net/wireless/intel/iwlegacy/common.c | 3 +--
> drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 12 ++++--------
> drivers/net/wireless/marvell/mwifiex/pcie.c | 8 ++------
> drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c | 4 ++--
> drivers/net/wireless/realtek/rtlwifi/pci.c | 6 ++----
> 15 files changed, 32 insertions(+), 51 deletions(-)
Do note that wireless patches go to wireless-drivers-next, not net-next.
But I assume Dave will ignore patches 5-10 and I can take them.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH wireless-drivers-next v2] mwifiex: use eth_broadcast_addr() to assign broadcast address
From: Kalle Valo @ 2019-07-24 11:56 UTC (permalink / raw)
To: Mao Wenan
Cc: amitkarwar, nishants, gbhat, huxinming820, linux-wireless,
kernel-janitors
In-Reply-To: <20190724062545.119041-1-maowenan@huawei.com>
Mao Wenan <maowenan@huawei.com> wrote:
> This patch is to use eth_broadcast_addr() to assign broadcast address
> insetad of memcpy().
>
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
15e830e90fde mwifiex: use eth_broadcast_addr() to assign broadcast address
--
https://patchwork.kernel.org/patch/11056129/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: remove assignment to itself
From: Kalle Valo @ 2019-07-24 11:55 UTC (permalink / raw)
To: pkshih; +Cc: dcb314, Larry.Finger, linux-wireless
In-Reply-To: <20190723031023.6777-1-pkshih@realtek.com>
<pkshih@realtek.com> wrote:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> Module parameters of 'sw_crypto' and 'disable_watchdog' are false by
> default. If new value is desired, we can do it during inserting module,
> assignment existing in source code is not reasonable.
>
> Reported-by: David Binderman <dcb314@hotmail.com>
> CC: Larry Finger <Larry.Finger@lwfinger.net>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
b43d6c8e8d7f rtlwifi: remove assignment to itself
--
https://patchwork.kernel.org/patch/11053745/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] brcmfmac: don't net_ratelimit() CONSOLE messages on firmware crash
From: Kalle Valo @ 2019-07-24 11:54 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Winnie Chang, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, Rafał Miłecki
In-Reply-To: <20190721195217.26838-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Firmware crash is a pretty rare event and can't happen too frequently as
> it has to be followed by a hardware reinitialization and config reload.
> It should be safe to don't use net_ratelimit() when it happens.
>
> For reporting & debugging purposes it's important to provide a complete
> log as the last lines are actually the most important. This change
> modifies brcmfmac to print all messages in an unlimited way in that
> specific case. With this change there should be finally a backtrace of
> firmware finally visible after a crash.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
e3b1d879ccda brcmfmac: don't net_ratelimit() CONSOLE messages on firmware crash
--
https://patchwork.kernel.org/patch/11051195/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] libertas_tf: Use correct channel range in lbtf_geo_init
From: Kalle Valo @ 2019-07-24 11:53 UTC (permalink / raw)
To: YueHaibing
Cc: davem, lkundrak, derosier, linux-kernel, netdev, linux-wireless,
YueHaibing
In-Reply-To: <20190716144218.20608-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> It seems we should use 'range' instead of 'priv->range'
> in lbtf_geo_init(), because 'range' is the corret one
> related to current regioncode.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: 691cdb49388b ("libertas_tf: command helper functions for libertas_tf")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
2ec4ad49b98e libertas_tf: Use correct channel range in lbtf_geo_init
--
https://patchwork.kernel.org/patch/11046191/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] rtw88: debug: dump tx power indexes in use
From: Kalle Valo @ 2019-07-24 11:53 UTC (permalink / raw)
To: yhchuang; +Cc: linux-wireless, briannorris
In-Reply-To: <1563254900-9219-1-git-send-email-yhchuang@realtek.com>
<yhchuang@realtek.com> wrote:
> From: Zong-Zhe Yang <kevin_yang@realtek.com>
>
> Add a read entry in debugfs to dump current tx power
> indexes in use for each path and each rate section.
> The corresponding power bases, power by rate, and
> power limit are also included.
>
> Also this patch fixes unused function warning.
>
> Fixes: b741422218ef ("rtw88: refine flow to get tx power index")
> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
8812022cb2fd rtw88: debug: dump tx power indexes in use
--
https://patchwork.kernel.org/patch/11045263/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: btcoex: fix issue possible condition with no effect (if == else)
From: Kalle Valo @ 2019-07-24 11:52 UTC (permalink / raw)
To: Hariprasad Kelam
Cc: Ping-Ke Shih, David S. Miller, YueHaibing, Hariprasad Kelam,
Larry Finger, Nathan Chancellor, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20190712191535.GA4215@hari-Inspiron-1545>
Hariprasad Kelam <hariprasad.kelam@gmail.com> wrote:
> fix below issue reported by coccicheck
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:514:1-3:
> WARNING: possible condition with no effect (if == else)
>
> Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
9a29f7d8476c rtlwifi: btcoex: fix issue possible condition with no effect (if == else)
--
https://patchwork.kernel.org/patch/11042665/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mt7601u: use params->ssn value directly
From: Kalle Valo @ 2019-07-24 11:52 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Jakub Kicinski
In-Reply-To: <20190712120949.GA21396@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> There is no point to use pointer to params->ssn.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> Acked-by: Jakub Kicinski <kubakici@wp.pl>
Patch applied to wireless-drivers-next.git, thanks.
f0248ec49bde mt7601u: use params->ssn value directly
--
https://patchwork.kernel.org/patch/11042213/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/7] Revert "brcmfmac: fix NULL pointer derefence during USB disconnect"
From: Kalle Valo @ 2019-07-24 11:51 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1562835912-1404-2-git-send-email-arend.vanspriel@broadcom.com>
Arend van Spriel <arend.vanspriel@broadcom.com> wrote:
> This reverts commit 5cdb0ef6144f47440850553579aa923c20a63f23. Subsequent
> changes make rework the driver code fixing the issue differently.
>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
7 patches applied to wireless-drivers-next.git, thanks.
a84a60ccdd65 Revert "brcmfmac: fix NULL pointer derefence during USB disconnect"
14fcfd1cc0c0 brcmfmac: change the order of things in brcmf_detach()
c613085b7494 brcmfmac: avoid firmware command in brcmf_netdev_open() when bus is down
c33330ac06fe brcmfmac: clear events in brcmf_fweh_detach() will always fail
1ac11ae949dd brcmfmac: avoid firmware commands when bus is down
e0bfb9601d48 brcmfmac: simply remove flowring if bus is down
4b11c915f00c brcmfmac: remove unnecessary strlcpy() upon obtaining "ver" iovar
--
https://patchwork.kernel.org/patch/11039459/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/3] brcmfmac: add 160MHz in chandef_to_chanspec()
From: Kalle Valo @ 2019-07-24 11:50 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1562834732-31508-2-git-send-email-arend.vanspriel@broadcom.com>
Arend van Spriel <arend.vanspriel@broadcom.com> wrote:
> The function chandef_to_chanspec() was not handling 160MHz bandwidth
> resulting in wrong encoding of the channel. That resulting in firmware
> rejecting the provided channel specification.
>
> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
3 patches applied to wireless-drivers-next.git, thanks.
f491645f0394 brcmfmac: add 160MHz in chandef_to_chanspec()
011a56a3336a brcmfmac: enable DFS_OFFLOAD extended feature if supported
fa9050927fa8 brcmfmac: allow 160MHz in custom regulatory rules
--
https://patchwork.kernel.org/patch/11039449/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v4 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
From: Kalle Valo @ 2019-07-24 11:49 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: Yan-Hsuan Chuang, David S . Miller, Larry Finger, David Laight,
Christoph Hellwig, linux-wireless, netdev, linux-kernel, linux,
Daniel Drake, Jian-Hong Pan, stable
In-Reply-To: <20190711052427.5582-1-jian-hong@endlessm.com>
Jian-Hong Pan <jian-hong@endlessm.com> wrote:
> Testing with RTL8822BE hardware, when available memory is low, we
> frequently see a kernel panic and system freeze.
>
> First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
>
> rx routine starvation
> WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822 rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
> [ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci]
>
> Then we see a variety of different error conditions and kernel panics,
> such as this one (trimmed):
>
> rtw_pci 0000:02:00.0: pci bus timeout, check dma status
> skbuff: skb_over_panic: text:00000000091b6e66 len:415 put:415 head:00000000d2880c6f data:000000007a02b1ea tail:0x1df end:0xc0 dev:<NULL>
> ------------[ cut here ]------------
> kernel BUG at net/core/skbuff.c:105!
> invalid opcode: 0000 [#1] SMP NOPTI
> RIP: 0010:skb_panic+0x43/0x45
>
> When skb allocation fails and the "rx routine starvation" is hit, the
> function returns immediately without updating the RX ring. At this
> point, the RX ring may continue referencing an old skb which was already
> handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
> bad things happen.
>
> This patch allocates a new, data-sized skb first in RX ISR. After
> copying the data in, we pass it to the upper layers. However, if skb
> allocation fails, we effectively drop the frame. In both cases, the
> original, full size ring skb is reused.
>
> In addition, to fixing the kernel crash, the RX routine should now
> generally behave better under low memory conditions.
>
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> Cc: <stable@vger.kernel.org>
2 patches applied to wireless-drivers-next.git, thanks.
ee6db78f5db9 rtw88: pci: Rearrange the memory usage for skb in RX ISR
29b68a920f6a rtw88: pci: Use DMA sync instead of remapping in RX ISR
--
https://patchwork.kernel.org/patch/11039275/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] libertas: Add missing sentinel at end of if_usb.c fw_table
From: Kalle Valo @ 2019-07-24 11:49 UTC (permalink / raw)
To: Kevin Easton
Cc: linux-wireless, andreyknvl, davem, libertas-dev, linux-kernel,
syzbot, netdev, syzkaller-bugs
In-Reply-To: <20190710133138.GA31901@ip-172-31-14-16>
Kevin Easton <kevin@guarana.org> wrote:
> This sentinel tells the firmware loading process when to stop.
>
> Reported-and-tested-by: syzbot+98156c174c5a2cad9f8f@syzkaller.appspotmail.com
> Signed-off-by: Kevin Easton <kevin@guarana.org>
Patch applied to wireless-drivers-next.git, thanks.
764f3f1ecffc libertas: Add missing sentinel at end of if_usb.c fw_table
--
https://patchwork.kernel.org/patch/11038493/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 09/12] rtw88: Fix misuse of GENMASK macro
From: Kalle Valo @ 2019-07-24 11:48 UTC (permalink / raw)
To: Joe Perches
Cc: Andrew Morton, Yan-Hsuan Chuang, David S. Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <0de52d891d7925b02f4f0fe2c750d076e55434d9.1562734889.git.joe@perches.com>
Joe Perches <joe@perches.com> wrote:
> Arguments are supposed to be ordered high then low.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
5ff29d836d1b rtw88: Fix misuse of GENMASK macro
--
https://patchwork.kernel.org/patch/11037805/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] libertas: Fix a double free in if_spi_c2h_data()
From: Kalle Valo @ 2019-07-24 11:46 UTC (permalink / raw)
To: Dan Williams
Cc: Philip Rakity, libertas-dev, kernel-janitors, linux-wireless,
Lubomir Rintel, Allison Randal, Dan Carpenter
In-Reply-To: <ee4472e4728becc9713962ba264742cb1f337098.camel@redhat.com>
Dan Williams <dcbw@redhat.com> wrote:
> The lbs_process_rxed_packet() frees the skb. It didn't originally, but
> we fixed it in commit f54930f36311 ("libertas: don't leak skb on receive
> error").
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
Failed to compile:
drivers/net/wireless/marvell/libertas/if_spi.c: In function 'if_spi_c2h_data':
drivers/net/wireless/marvell/libertas/if_spi.c:771:11: error: expected ';' before '}' token
goto out
^
;
}
~
make[5]: *** [drivers/net/wireless/marvell/libertas/if_spi.o] Error 1
make[4]: *** [drivers/net/wireless/marvell/libertas] Error 2
make[3]: *** [drivers/net/wireless/marvell] Error 2
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/11033059/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] wl3501_cs: remove redundant variable rc
From: Kalle Valo @ 2019-07-24 11:45 UTC (permalink / raw)
To: Colin King
Cc: David S . Miller, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20190705103732.30568-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The variable rc is being initialized with a value that is never
> read and it is being updated later with a new value that is returned.
> The variable is redundant and can be replaced with a return 0 as
> there are no other return points in this function.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
c032461936de wl3501_cs: remove redundant variable rc
--
https://patchwork.kernel.org/patch/11032441/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] libertas: remove redundant assignment to variable ret
From: Kalle Valo @ 2019-07-24 11:44 UTC (permalink / raw)
To: Colin King
Cc: David S . Miller, libertas-dev, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20190705081734.15292-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The variable ret is being initialized with a value that is never
> read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
4c8a46851019 libertas: remove redundant assignment to variable ret
--
https://patchwork.kernel.org/patch/11032181/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Kalle Valo @ 2019-07-24 11:44 UTC (permalink / raw)
To: Chris Chiu
Cc: jes.sorensen, davem, linux-wireless, netdev, linux-kernel, linux
In-Reply-To: <20190704105528.74028-1-chiu@endlessm.com>
Chris Chiu <chiu@endlessm.com> wrote:
> The WiFi tx power of RTL8723BU is extremely low after booting. So
> the WiFi scan gives very limited AP list and it always fails to
> connect to the selected AP. This module only supports 1x1 antenna
> and the antenna is switched to bluetooth due to some incorrect
> register settings.
>
> Compare with the vendor driver https://github.com/lwfinger/rtl8723bu,
> we realized that the 8723bu's enable_rf() does the same thing as
> rtw_btcoex_HAL_Initialize() in vendor driver. And it by default
> sets the antenna path to BTC_ANT_PATH_BT which we verified it's
> the cause of the wifi weak tx power. The vendor driver will set
> the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist
> mechanism, by the function halbtc8723b1ant_PsTdma.
>
> This commit hand over the antenna control to PTA(Packet Traffic
> Arbitration), which compares the weight of bluetooth/wifi traffic
> then determine whether to continue current wifi traffic or not.
> After PTA take control, The wifi signal will be back to normal and
> the bluetooth scan can also work at the same time. However, the
> btcoexist still needs to be handled under different circumstances.
> If there's a BT connection established, the wifi still fails to
> connect until BT disconnected.
>
> Signed-off-by: Chris Chiu <chiu@endlessm.com>
Patch applied to wireless-drivers-next.git, thanks.
18e714687bea rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
--
https://patchwork.kernel.org/patch/11031397/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] rt2x00: no need to check return value of debugfs_create functions
From: Kalle Valo @ 2019-07-24 11:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Stanislaw Gruszka, Helmut Schaa, David S. Miller, linux-wireless,
netdev
In-Reply-To: <20190703113956.GA26652@kroah.com>
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Because we don't need to save the individual debugfs files and
> directories, remove the local storage of them and just remove the entire
> debugfs directory in a single call, making things a lot simpler.
>
> Cc: Stanislaw Gruszka <sgruszka@redhat.com>
> Cc: Helmut Schaa <helmut.schaa@googlemail.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
1dc244064c47 rt2x00: no need to check return value of debugfs_create functions
--
https://patchwork.kernel.org/patch/11029367/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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