* Re: [PATCH][next] qtnfmac: replace qtnf_cmd_acl_data_size() with struct_size()
From: Sergey Matyukevich @ 2019-04-04 13:32 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo,
David S. Miller, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190403170236.GA31637@embeddedor>
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = kzalloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> size = struct_size(instance, entry, count);
>
> or
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL)
>
> Based on the above, replace qtnf_cmd_acl_data_size() with the
> new struct_size() helper.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> drivers/net/wireless/quantenna/qtnfmac/commands.c | 15 ++++-----------
> 1 file changed, 4 insertions(+), 11 deletions(-)
Hi Gustavo,
Thanks for the patch! By the way, it does not apply cleanly, so it needs
to be rebased on top of the up-to-date wireless-drivers-next tree. Let
me know if you would prefer me to care about rebase. Then I will
add this patch to the upcoming series of qtnfmac fixes.
Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Regards,
Sergey
^ permalink raw reply
* Re: FW: [PATCH v2] ath10k: Report low ack rssi based on the reason code
From: Rakesh Pillai @ 2019-04-04 12:11 UTC (permalink / raw)
To: peter.oh; +Cc: ath10k, linux-wireless
In-Reply-To: <8c3110f20aec4c4a90bb679c4551b1fc@aphydexm01b.ap.qualcomm.com>
>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
>> b/drivers/net/wireless/ath/ath10k/wmi.h
>> index e1c40bb..3ccd79e 100644
>> --- a/drivers/net/wireless/ath/ath10k/wmi.h
>> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
>> @@ -6797,6 +6797,8 @@ struct wmi_vdev_start_ev_arg {
>>
>> struct wmi_peer_kick_ev_arg {
>> const u8 *mac_addr;
>> + u32 reason;
>> + bool reason_code_valid;
>> };
>>
> Adding extra members to this structure breaks structure consistency
> between FW and host driver since FW doesn't have such members.
>
> Peter
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
struct wmi_peer_sta_kickout_event is used for parsing event from non-tlv
firmwares and
struct wmi_tlv_peer_sta_kickout_event is used for parsing event from
tlv firmwares.
Both of the above structures maintain consistency with the respective
FW.
struct wmi_peer_kick_ev_arg is used only for internal ath10k operations
only.
Thanks,
Rakesh Pillai.
^ permalink raw reply
* Re: [PATCH] rtlwifi: move spin_lock_bh to spin_lock in tasklet
From: Kalle Valo @ 2019-04-04 10:27 UTC (permalink / raw)
To: Jeff Xie
Cc: pkshih, davem, linux-wireless, netdev, linux-kernel, chongguiguzi
In-Reply-To: <1553005870-28018-1-git-send-email-chongguiguzi@gmail.com>
Jeff Xie <chongguiguzi@gmail.com> wrote:
> It is unnecessary to call spin_lock_bh in a tasklet.
>
> Signed-off-by: Jeff Xie <chongguiguzi@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
38bb0baea310 rtlwifi: move spin_lock_bh to spin_lock in tasklet
--
https://patchwork.kernel.org/patch/10859681/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: fix potential NULL pointer dereference
From: Kalle Valo @ 2019-04-04 10:25 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, Larry.Finger, kjlu
In-Reply-To: <20190312090648.30750-1-pkshih@realtek.com>
<pkshih@realtek.com> wrote:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> In case dev_alloc_skb fails, the fix safely returns to avoid
> potential NULL pointer dereference.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
60209d482b97 rtlwifi: fix potential NULL pointer dereference
--
https://patchwork.kernel.org/patch/10848803/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: fix a potential NULL pointer dereference
From: Kalle Valo @ 2019-04-04 10:25 UTC (permalink / raw)
To: Kangjie Lu
Cc: kjlu, pakki001, Ping-Ke Shih, David S. Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20190312075633.573-1-kjlu@umn.edu>
Kangjie Lu <kjlu@umn.edu> wrote:
> In case alloc_workqueue fails, the fix reports the error and
> returns to avoid NULL pointer dereference.
>
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Patch applied to wireless-drivers-next.git, thanks.
765976285a8c rtlwifi: fix a potential NULL pointer dereference
--
https://patchwork.kernel.org/patch/10848697/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/2] rtlwifi: Fix duplicate tests of one of the RX descriptors
From: Kalle Valo @ 2019-04-04 10:24 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190304215940.2608-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> In drivers rtl8188ee, rtl8821ae, rtl8723be, and rtl8192ee, the reason
> for a wake-up is returned in the fourth RX descriptor in bits 29-31. Due
> to typographical errors, all but rtl8821ae test bit 31 twice and fail to
> test bit 29.
>
> This error causes no problems as the tests are only used to set bits in
> a quantity output in an optional debugging statement.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Failed to apply:
fatal: sha1 information is lacking or useless (drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c).
error: could not build fake ancestor
Applying: rtlwifi: Convert the wake_match variable to local
Patch failed at 0001 rtlwifi: Convert the wake_match variable to local
The copy of the patch that failed is found in: .git/rebase-apply/patch
2 patches set to Changes Requested.
10838677 [1/2] rtlwifi: Fix duplicate tests of one of the RX descriptors
10838679 [2/2] rtlwifi: Convert the wake_match variable to local
--
https://patchwork.kernel.org/patch/10838677/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 3/4] mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling it too late
From: Kalle Valo @ 2019-04-04 10:22 UTC (permalink / raw)
To: Marc Zyngier
Cc: Amitkumar Karwar, Enric Balletbo i Serra, Ganapathi Bhat,
Heiko Stuebner, Nishant Sarmukadam, Rob Herring, Xinming Hu,
David S. Miller, devicetree, linux-arm-kernel, linux-kernel,
linux-rockchip, linux-wireless, netdev
In-Reply-To: <20190224140426.3267-4-marc.zyngier@arm.com>
Marc Zyngier <marc.zyngier@arm.com> wrote:
> The mwifiex driver makes unsafe assumptions about the state of the
> wake-up interrupt. It requests it and only then disable it. Of
> course, the interrupt may be screaming for whatever reason at that
> time, and the handler will then be called without the interrupt
> having been registered with the PM/wakeup subsystem. Oops.
>
> The right way to handle this kind of situation is to flag the
> interrupt with IRQ_NOAUTOEN before requesting it. It will then
> stay disabled until someone (the wake-up subsystem) enables it.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
Failed to apply:
fatal: sha1 information is lacking or useless (drivers/net/wireless/marvell/mwifiex/main.c).
error: could not build fake ancestor
Applying: mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling it too late
Patch failed at 0001 mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling it too late
The copy of the patch that failed is found in: .git/rebase-apply/patch
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/10827971/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwifiex: add a bounds check in mwifiex_process_sta_rx_packet()
From: Kalle Valo @ 2019-04-04 10:21 UTC (permalink / raw)
To: Dan Carpenter
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
linux-wireless, kernel-janitors
In-Reply-To: <20190402070338.GB15171@kadam>
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Smatch complains that "local_rx_pd->priority" can't be trusted because
> it comes from skb->data and it can go up to 255 instead of being capped
> in the 0-7 range. A few lines earlier, on the other side of the if
> statement, we cap priority so it seems harmless to add a bounds check
> here as well.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
2cd2b42439ea mwifiex: add a bounds check in mwifiex_process_sta_rx_packet()
--
https://patchwork.kernel.org/patch/10881135/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwifiex: Fix potential NULL pointer dereference
From: Kalle Valo @ 2019-04-04 10:20 UTC (permalink / raw)
To: Aditya Pakki
Cc: pakki001, kjlu, Amitkumar Karwar, Nishant Sarmukadam,
Ganapathi Bhat, Xinming Hu, David S. Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20190313184229.24780-1-pakki001@umn.edu>
Aditya Pakki <pakki001@umn.edu> wrote:
> dev_alloc_skb can fail and return a NULL pointer. The patch avoids
> a potential NULL pointer dereference and returns -ENOMEM.
>
> Signed-off-by: Aditya Pakki <pakki001@umn.edu>
A similar patch was already submitted:
https://patchwork.kernel.org/patch/10848599/
Patch set to Superseded.
--
https://patchwork.kernel.org/patch/10851669/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwifiex: Fix mem leak in mwifiex_tm_cmd
From: Kalle Valo @ 2019-04-04 10:19 UTC (permalink / raw)
To: Yue Haibing
Cc: amitkarwar, nishants, gbhat, huxinming820, davem, linux-kernel,
netdev, linux-wireless, YueHaibing
In-Reply-To: <20190312070358.12700-1-yuehaibing@huawei.com>
Yue Haibing <yuehaibing@huawei.com> wrote:
> From: YueHaibing <yuehaibing@huawei.com>
>
> 'hostcmd' is alloced by kzalloc, should be freed before
> leaving from the error handling cases, otherwise it will
> cause mem leak.
>
> Fixes: 3935ccc14d2c ("mwifiex: add cfg80211 testmode support")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
003b686ace82 mwifiex: Fix mem leak in mwifiex_tm_cmd
--
https://patchwork.kernel.org/patch/10848633/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] net: mwifiex: fix a NULL pointer dereference
From: Kalle Valo @ 2019-04-04 10:18 UTC (permalink / raw)
To: Kangjie Lu
Cc: kjlu, pakki001, Amitkumar Karwar, Nishant Sarmukadam,
Ganapathi Bhat, Xinming Hu, David S. Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20190312053107.5790-1-kjlu@umn.edu>
Kangjie Lu <kjlu@umn.edu> wrote:
> In case dev_alloc_skb fails, the fix returns -ENOMEM to avoid
> NULL pointer dereference.
>
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Patch applied to wireless-drivers-next.git, thanks.
e5b9b206f3f6 net: mwifiex: fix a NULL pointer dereference
--
https://patchwork.kernel.org/patch/10848599/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] iwlegacy: remove redundant assignment to *res
From: Kalle Valo @ 2019-04-04 10:15 UTC (permalink / raw)
To: Colin King
Cc: Stanislaw Gruszka, David S . Miller, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20190330201422.8024-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently 1 is being assigned to *res and then it is immediately
> updated with the computed result. The first assignment is
> redundant and can be removed.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Patch applied to wireless-drivers-next.git, thanks.
6603c5844a44 iwlegacy: remove redundant assignment to *res
--
https://patchwork.kernel.org/patch/10878565/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] b43: shut up clang -Wuninitialized variable warning
From: Kalle Valo @ 2019-04-04 10:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Larry Finger, Arnd Bergmann, Priit Laes,
clang-built-linux, Nick Desaulniers, Nathan Chancellor,
linux-wireless, b43-dev, netdev, linux-kernel
In-Reply-To: <20190322143725.1332353-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> Clang warns about what is clearly a case of passing an uninitalized
> variable into a static function:
>
> drivers/net/wireless/broadcom/b43/phy_lp.c:1852:23: error: variable 'gains' is uninitialized when used here
> [-Werror,-Wuninitialized]
> lpphy_papd_cal(dev, gains, 0, 1, 30);
> ^~~~~
> drivers/net/wireless/broadcom/b43/phy_lp.c:1838:2: note: variable 'gains' is declared here
> struct lpphy_tx_gains gains, oldgains;
> ^
> 1 error generated.
>
> However, this function is empty, and its arguments are never evaluated,
> so gcc in contrast does not warn here. Both compilers behave in a
> reasonable way as far as I can tell, so we should change the code
> to avoid the warning everywhere.
>
> We could just eliminate the lpphy_papd_cal() function entirely,
> given that it has had the TODO comment in it for 10 years now
> and is rather unlikely to ever get done. I'm doing a simpler
> change here, and just pass the 'oldgains' variable in that has
> been initialized, based on the guess that this is what was
> originally meant.
>
> Fixes: 2c0d6100da3e ("b43: LP-PHY: Begin implementing calibration & software RFKILL support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
d825db346270 b43: shut up clang -Wuninitialized variable warning
--
https://patchwork.kernel.org/patch/10865933/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3] brcmfmac: fix missing checks for kmemdup
From: Kalle Valo @ 2019-04-04 10:13 UTC (permalink / raw)
To: Kangjie Lu
Cc: kjlu, pakki001, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, David S. Miller,
Rafał Miłecki, Stefan Wahren, Chung-Hsien Hsu,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
netdev, linux-kernel
In-Reply-To: <20190315170433.3845-1-kjlu@umn.edu>
Kangjie Lu <kjlu@umn.edu> wrote:
> In case kmemdup fails, the fix sets conn_info->req_ie_len and
> conn_info->resp_ie_len to zero to avoid buffer overflows.
>
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
46953f97224d brcmfmac: fix missing checks for kmemdup
--
https://patchwork.kernel.org/patch/10855341/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] brcmfmac: convert dev_init_lock mutex to completion
From: Kalle Valo @ 2019-04-04 10:13 UTC (permalink / raw)
To: Piotr Figiel
Cc: linux-wireless@vger.kernel.org, arend.vanspriel@broadcom.com,
franky.lin@broadcom.com, hante.meuleman@broadcom.com,
chi-hsien.lin@cypress.com, wright.feng@cypress.com,
brcm80211-dev-list@cypress.com, Krzysztof Drobiński,
Pawel Lenkow, Lech Perczak, Piotr Figiel
In-Reply-To: <1552470749-3625-1-git-send-email-p.figiel@camlintechnologies.com>
Piotr Figiel <p.figiel@camlintechnologies.com> wrote:
> Leaving dev_init_lock mutex locked in probe causes BUG and a WARNING when
> kernel is compiled with CONFIG_PROVE_LOCKING. Convert mutex to completion
> which silences those warnings and improves code readability.
>
> Fix below errors when connecting the USB WiFi dongle:
>
> brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43143 for chip BCM43143/2
> BUG: workqueue leaked lock or atomic: kworker/0:2/0x00000000/434
> last function: hub_event
> 1 lock held by kworker/0:2/434:
> #0: 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
> CPU: 0 PID: 434 Comm: kworker/0:2 Not tainted 4.19.23-00084-g454a789-dirty #123
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> Workqueue: usb_hub_wq hub_event
> [<8011237c>] (unwind_backtrace) from [<8010d74c>] (show_stack+0x10/0x14)
> [<8010d74c>] (show_stack) from [<809c4324>] (dump_stack+0xa8/0xd4)
> [<809c4324>] (dump_stack) from [<8014195c>] (process_one_work+0x710/0x808)
> [<8014195c>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
> [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
> [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
> Exception stack(0xed1d9fb0 to 0xed1d9ff8)
> 9fa0: 00000000 00000000 00000000 00000000
> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
>
> ======================================================
> WARNING: possible circular locking dependency detected
> 4.19.23-00084-g454a789-dirty #123 Not tainted
> ------------------------------------------------------
> kworker/0:2/434 is trying to acquire lock:
> e29cf799 ((wq_completion)"events"){+.+.}, at: process_one_work+0x174/0x808
>
> but task is already holding lock:
> 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #2 (&devinfo->dev_init_lock){+.+.}:
> mutex_lock_nested+0x1c/0x24
> brcmf_usb_probe+0x78/0x550 [brcmfmac]
> usb_probe_interface+0xc0/0x1bc
> really_probe+0x228/0x2c0
> __driver_attach+0xe4/0xe8
> bus_for_each_dev+0x68/0xb4
> bus_add_driver+0x19c/0x214
> driver_register+0x78/0x110
> usb_register_driver+0x84/0x148
> process_one_work+0x228/0x808
> worker_thread+0x2c/0x564
> kthread+0x13c/0x16c
> ret_from_fork+0x14/0x20
> (null)
>
> -> #1 (brcmf_driver_work){+.+.}:
> worker_thread+0x2c/0x564
> kthread+0x13c/0x16c
> ret_from_fork+0x14/0x20
> (null)
>
> -> #0 ((wq_completion)"events"){+.+.}:
> process_one_work+0x1b8/0x808
> worker_thread+0x2c/0x564
> kthread+0x13c/0x16c
> ret_from_fork+0x14/0x20
> (null)
>
> other info that might help us debug this:
>
> Chain exists of:
> (wq_completion)"events" --> brcmf_driver_work --> &devinfo->dev_init_lock
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(&devinfo->dev_init_lock);
> lock(brcmf_driver_work);
> lock(&devinfo->dev_init_lock);
> lock((wq_completion)"events");
>
> *** DEADLOCK ***
>
> 1 lock held by kworker/0:2/434:
> #0: 18d5dcdf (&devinfo->dev_init_lock){+.+.}, at: brcmf_usb_probe+0x78/0x550 [brcmfmac]
>
> stack backtrace:
> CPU: 0 PID: 434 Comm: kworker/0:2 Not tainted 4.19.23-00084-g454a789-dirty #123
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> Workqueue: events request_firmware_work_func
> [<8011237c>] (unwind_backtrace) from [<8010d74c>] (show_stack+0x10/0x14)
> [<8010d74c>] (show_stack) from [<809c4324>] (dump_stack+0xa8/0xd4)
> [<809c4324>] (dump_stack) from [<80172838>] (print_circular_bug+0x210/0x330)
> [<80172838>] (print_circular_bug) from [<80175940>] (__lock_acquire+0x160c/0x1a30)
> [<80175940>] (__lock_acquire) from [<8017671c>] (lock_acquire+0xe0/0x268)
> [<8017671c>] (lock_acquire) from [<80141404>] (process_one_work+0x1b8/0x808)
> [<80141404>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
> [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
> [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
> Exception stack(0xed1d9fb0 to 0xed1d9ff8)
> 9fa0: 00000000 00000000 00000000 00000000
> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
>
> Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com>
Patch applied to wireless-drivers-next.git, thanks.
a9fd0953fa4a brcmfmac: convert dev_init_lock mutex to completion
--
https://patchwork.kernel.org/patch/10850843/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] brcmfmac: fix Oops when bringing up interface during USB disconnect
From: Kalle Valo @ 2019-04-04 10:11 UTC (permalink / raw)
To: Piotr Figiel
Cc: linux-wireless@vger.kernel.org, arend.vanspriel@broadcom.com,
franky.lin@broadcom.com, hante.meuleman@broadcom.com,
chi-hsien.lin@cypress.com, wright.feng@cypress.com,
brcm80211-dev-list@cypress.com, Krzysztof Drobiński,
Pawel Lenkow, Lech Perczak, Piotr Figiel
In-Reply-To: <1552470712-3496-1-git-send-email-p.figiel@camlintechnologies.com>
Piotr Figiel <p.figiel@camlintechnologies.com> wrote:
> Fix a race which leads to an Oops with NULL pointer dereference. The
> dereference is in brcmf_config_dongle() when cfg_to_ndev() attempts to get
> net_device structure of interface with index 0 via if2bss mapping. This
> shouldn't fail because of check for bus being ready in brcmf_netdev_open(),
> but it's not synchronised with USB disconnect and there is a race: after
> the check the bus can be marked down and the mapping for interface 0 may be
> gone.
>
> Solve this by modifying disconnect handling so that the removal of mapping
> of ifidx to brcmf_if structure happens after netdev removal (which is
> synchronous with brcmf_netdev_open() thanks to rtln being locked in
> devinet_ioctl()). This assures brcmf_netdev_open() returns before the
> mapping is removed during disconnect.
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000008
> pgd = bcae2612
> [00000008] *pgd=8be73831
> Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> Modules linked in: brcmfmac brcmutil nf_log_ipv4 nf_log_common xt_LOG xt_limit
> iptable_mangle xt_connmark xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6
> nf_defrag_ipv4 iptable_filter ip_tables x_tables usb_f_mass_storage usb_f_rndis
> u_ether usb_serial_simple usbserial cdc_acm smsc95xx usbnet ci_hdrc_imx ci_hdrc
> usbmisc_imx ulpi 8250_exar 8250_pci 8250 8250_base libcomposite configfs
> udc_core [last unloaded: brcmutil]
> CPU: 2 PID: 24478 Comm: ifconfig Not tainted 4.19.23-00078-ga62866d-dirty #115
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> PC is at brcmf_cfg80211_up+0x94/0x29c [brcmfmac]
> LR is at brcmf_cfg80211_up+0x8c/0x29c [brcmfmac]
> pc : [<7f26a91c>] lr : [<7f26a914>] psr: a0070013
> sp : eca99d28 ip : 00000000 fp : ee9c6c00
> r10: 00000036 r9 : 00000000 r8 : ece4002c
> r7 : edb5b800 r6 : 00000000 r5 : 80f08448 r4 : edb5b968
> r3 : ffffffff r2 : 00000000 r1 : 00000002 r0 : 00000000
> Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 7ca0c04a DAC: 00000051
> Process ifconfig (pid: 24478, stack limit = 0xd9e85a0e)
> Stack: (0xeca99d28 to 0xeca9a000)
> 9d20: 00000000 80f873b0 0000000d 80f08448 eca99d68 50d45f32
> 9d40: 7f27de94 ece40000 80f08448 80f08448 7f27de94 ece4002c 00000000 00000036
> 9d60: ee9c6c00 7f27262c 00001002 50d45f32 ece40000 00000000 80f08448 80772008
> 9d80: 00000001 00001043 00001002 ece40000 00000000 50d45f32 ece40000 00000001
> 9da0: 80f08448 00001043 00001002 807723d0 00000000 50d45f32 80f08448 eca99e58
> 9dc0: 80f87113 50d45f32 80f08448 ece40000 ece40138 00001002 80f08448 00000000
> 9de0: 00000000 80772434 edbd5380 eca99e58 edbd5380 80f08448 ee9c6c0c 80805f70
> 9e00: 00000000 ede08e00 00008914 ece40000 00000014 ee9c6c0c 600c0013 00001043
> 9e20: 0208a8c0 ffffffff 00000000 50d45f32 eca98000 80f08448 7ee9fc38 00008914
> 9e40: 80f68e40 00000051 eca98000 00000036 00000003 80808b9c 6e616c77 00000030
> 9e60: 00000000 00000000 00001043 0208a8c0 ffffffff 00000000 80f08448 00000000
> 9e80: 00000000 816d8b20 600c0013 00000001 ede09320 801763d4 00000000 50d45f32
> 9ea0: eca98000 80f08448 7ee9fc38 50d45f32 00008914 80f08448 7ee9fc38 80f68e40
> 9ec0: ed531540 8074721c 00000800 00000001 00000000 6e616c77 00000030 00000000
> 9ee0: 00000000 00001002 0208a8c0 ffffffff 00000000 50d45f32 80f08448 7ee9fc38
> 9f00: ed531560 ec8fc900 80285a6c 80285138 edb910c0 00000000 ecd91008 ede08e00
> 9f20: 80f08448 00000000 00000000 816d8b20 600c0013 00000001 ede09320 801763d4
> 9f40: 00000000 50d45f32 00021000 edb91118 edb910c0 80f08448 01b29000 edb91118
> 9f60: eca99f7c 50d45f32 00021000 ec8fc900 00000003 ec8fc900 00008914 7ee9fc38
> 9f80: eca98000 00000036 00000003 80285a6c 00086364 7ee9fe1c 000000c3 00000036
> 9fa0: 801011c4 80101000 00086364 7ee9fe1c 00000003 00008914 7ee9fc38 00086364
> 9fc0: 00086364 7ee9fe1c 000000c3 00000036 0008630c 7ee9fe1c 7ee9fc38 00000003
> 9fe0: 000a42b8 7ee9fbd4 00019914 76e09acc 600c0010 00000003 00000000 00000000
> [<7f26a91c>] (brcmf_cfg80211_up [brcmfmac]) from [<7f27262c>] (brcmf_netdev_open+0x74/0xe8 [brcmfmac])
> [<7f27262c>] (brcmf_netdev_open [brcmfmac]) from [<80772008>] (__dev_open+0xcc/0x150)
> [<80772008>] (__dev_open) from [<807723d0>] (__dev_change_flags+0x168/0x1b4)
> [<807723d0>] (__dev_change_flags) from [<80772434>] (dev_change_flags+0x18/0x48)
> [<80772434>] (dev_change_flags) from [<80805f70>] (devinet_ioctl+0x67c/0x79c)
> [<80805f70>] (devinet_ioctl) from [<80808b9c>] (inet_ioctl+0x210/0x3d4)
> [<80808b9c>] (inet_ioctl) from [<8074721c>] (sock_ioctl+0x350/0x524)
> [<8074721c>] (sock_ioctl) from [<80285138>] (do_vfs_ioctl+0xb0/0x9b0)
> [<80285138>] (do_vfs_ioctl) from [<80285a6c>] (ksys_ioctl+0x34/0x5c)
> [<80285a6c>] (ksys_ioctl) from [<80101000>] (ret_fast_syscall+0x0/0x28)
> Exception stack(0xeca99fa8 to 0xeca99ff0)
> 9fa0: 00086364 7ee9fe1c 00000003 00008914 7ee9fc38 00086364
> 9fc0: 00086364 7ee9fe1c 000000c3 00000036 0008630c 7ee9fe1c 7ee9fc38 00000003
> 9fe0: 000a42b8 7ee9fbd4 00019914 76e09acc
> Code: e5970328 eb002021 e1a02006 e3a01002 (e5909008)
> ---[ end trace 5cbac2333f3ac5df ]---
>
> Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com>
Patch applied to wireless-drivers-next.git, thanks.
24d413a31afa brcmfmac: fix Oops when bringing up interface during USB disconnect
--
https://patchwork.kernel.org/patch/10850845/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/3] brcmfmac: fix race during disconnect when USB completion is in progress
From: Kalle Valo @ 2019-04-04 10:11 UTC (permalink / raw)
To: Piotr Figiel
Cc: linux-wireless@vger.kernel.org, arend.vanspriel@broadcom.com,
franky.lin@broadcom.com, hante.meuleman@broadcom.com,
chi-hsien.lin@cypress.com, wright.feng@cypress.com,
brcm80211-dev-list@cypress.com, Pawel Lenkow, Lech Perczak,
Krzysztof Drobiński, Piotr Figiel
In-Reply-To: <1552058658-23250-2-git-send-email-p.figiel@camlintechnologies.com>
Piotr Figiel <p.figiel@camlintechnologies.com> wrote:
> It was observed that rarely during USB disconnect happening shortly after
> connect (before full initialization completes) usb_hub_wq would wait
> forever for the dev_init_lock to be unlocked. dev_init_lock would remain
> locked though because of infinite wait during usb_kill_urb:
>
> [ 2730.656472] kworker/0:2 D 0 260 2 0x00000000
> [ 2730.660700] Workqueue: events request_firmware_work_func
> [ 2730.664807] [<809dca20>] (__schedule) from [<809dd164>] (schedule+0x4c/0xac)
> [ 2730.670587] [<809dd164>] (schedule) from [<8069af44>] (usb_kill_urb+0xdc/0x114)
> [ 2730.676815] [<8069af44>] (usb_kill_urb) from [<7f258b50>] (brcmf_usb_free_q+0x34/0xa8 [brcmfmac])
> [ 2730.684833] [<7f258b50>] (brcmf_usb_free_q [brcmfmac]) from [<7f2517d4>] (brcmf_detach+0xa0/0xb8 [brcmfmac])
> [ 2730.693557] [<7f2517d4>] (brcmf_detach [brcmfmac]) from [<7f251a34>] (brcmf_attach+0xac/0x3d8 [brcmfmac])
> [ 2730.702094] [<7f251a34>] (brcmf_attach [brcmfmac]) from [<7f2587ac>] (brcmf_usb_probe_phase2+0x468/0x4a0 [brcmfmac])
> [ 2730.711601] [<7f2587ac>] (brcmf_usb_probe_phase2 [brcmfmac]) from [<7f252888>] (brcmf_fw_request_done+0x194/0x220 [brcmfmac])
> [ 2730.721795] [<7f252888>] (brcmf_fw_request_done [brcmfmac]) from [<805748e4>] (request_firmware_work_func+0x4c/0x88)
> [ 2730.731125] [<805748e4>] (request_firmware_work_func) from [<80141474>] (process_one_work+0x228/0x808)
> [ 2730.739223] [<80141474>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
> [ 2730.746105] [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
> [ 2730.752227] [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
>
> [ 2733.099695] kworker/0:3 D 0 1065 2 0x00000000
> [ 2733.103926] Workqueue: usb_hub_wq hub_event
> [ 2733.106914] [<809dca20>] (__schedule) from [<809dd164>] (schedule+0x4c/0xac)
> [ 2733.112693] [<809dd164>] (schedule) from [<809e2a8c>] (schedule_timeout+0x214/0x3e4)
> [ 2733.119621] [<809e2a8c>] (schedule_timeout) from [<809dde2c>] (wait_for_common+0xc4/0x1c0)
> [ 2733.126810] [<809dde2c>] (wait_for_common) from [<7f258d00>] (brcmf_usb_disconnect+0x1c/0x4c [brcmfmac])
> [ 2733.135206] [<7f258d00>] (brcmf_usb_disconnect [brcmfmac]) from [<8069e0c8>] (usb_unbind_interface+0x5c/0x1e4)
> [ 2733.143943] [<8069e0c8>] (usb_unbind_interface) from [<8056d3e8>] (device_release_driver_internal+0x164/0x1fc)
> [ 2733.152769] [<8056d3e8>] (device_release_driver_internal) from [<8056c078>] (bus_remove_device+0xd0/0xfc)
> [ 2733.161138] [<8056c078>] (bus_remove_device) from [<8056977c>] (device_del+0x11c/0x310)
> [ 2733.167939] [<8056977c>] (device_del) from [<8069cba8>] (usb_disable_device+0xa0/0x1cc)
> [ 2733.174743] [<8069cba8>] (usb_disable_device) from [<8069507c>] (usb_disconnect+0x74/0x1dc)
> [ 2733.181823] [<8069507c>] (usb_disconnect) from [<80695e88>] (hub_event+0x478/0xf88)
> [ 2733.188278] [<80695e88>] (hub_event) from [<80141474>] (process_one_work+0x228/0x808)
> [ 2733.194905] [<80141474>] (process_one_work) from [<80141a80>] (worker_thread+0x2c/0x564)
> [ 2733.201724] [<80141a80>] (worker_thread) from [<80147bcc>] (kthread+0x13c/0x16c)
> [ 2733.207913] [<80147bcc>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20)
>
> It was traced down to a case where usb_kill_urb would be called on an URB
> structure containing more or less random data, including large number in
> its use_count. During the debugging it appeared that in brcmf_usb_free_q()
> the traversal over URBs' lists is not synchronized with operations on those
> lists in brcmf_usb_rx_complete() leading to handling
> brcmf_usbdev_info structure (holding lists' head) as lists' element and in
> result causing above problem.
>
> Fix it by walking through all URBs during brcmf_cancel_all_urbs using the
> arrays of requests instead of linked lists.
>
> Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com>
3 patches applied to wireless-drivers-next.git, thanks.
db3b9e2e1d58 brcmfmac: fix race during disconnect when USB completion is in progress
2b78e5f52236 brcmfmac: remove pending parameter from brcmf_usb_free_q
504f06725d01 brcmfmac: remove unused variable i from brcmf_usb_free_q
--
https://patchwork.kernel.org/patch/10845051/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/2] brcmfmac: fix WARNING during USB disconnect in case of unempty psq
From: Kalle Valo @ 2019-04-04 10:10 UTC (permalink / raw)
To: Piotr Figiel
Cc: linux-wireless@vger.kernel.org, arend.vanspriel@broadcom.com,
franky.lin@broadcom.com, hante.meuleman@broadcom.com,
chi-hsien.lin@cypress.com, wright.feng@cypress.com,
brcm80211-dev-list@cypress.com, Piotr Figiel
In-Reply-To: <1551714128-27412-2-git-send-email-p.figiel@camlintechnologies.com>
Piotr Figiel <p.figiel@camlintechnologies.com> wrote:
> brcmu_pkt_buf_free_skb emits WARNING when attempting to free a sk_buff
> which is part of any queue. After USB disconnect this may have happened
> when brcmf_fws_hanger_cleanup() is called as per-interface psq was never
> cleaned when removing the interface.
> Change brcmf_fws_macdesc_cleanup() in a way that it removes the
> corresponding packets from hanger table (to avoid double-free when
> brcmf_fws_hanger_cleanup() is called) and add a call to clean-up the
> interface specific packet queue.
>
> Below is a WARNING during USB disconnect with Raspberry Pi WiFi dongle
> running in AP mode. This was reproducible when the interface was
> transmitting during the disconnect and is fixed with this commit.
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1171 at drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c:49 brcmu_pkt_buf_free_skb+0x3c/0x40
> Modules linked in: nf_log_ipv4 nf_log_common xt_LOG xt_limit iptable_mangle xt_connmark xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter ip_tables x_tables usb_f_mass_storage usb_f_rndis u_ether cdc_acm smsc95xx usbnet ci_hdrc_imx ci_hdrc ulpi usbmisc_imx 8250_exar 8250_pci 8250 8250_base libcomposite configfs udc_core
> CPU: 0 PID: 1171 Comm: kworker/0:0 Not tainted 4.19.23-00075-gde33ed8 #99
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> Workqueue: usb_hub_wq hub_event
> [<8010ff84>] (unwind_backtrace) from [<8010bb64>] (show_stack+0x10/0x14)
> [<8010bb64>] (show_stack) from [<80840278>] (dump_stack+0x88/0x9c)
> [<80840278>] (dump_stack) from [<8011f5ec>] (__warn+0xfc/0x114)
> [<8011f5ec>] (__warn) from [<8011f71c>] (warn_slowpath_null+0x40/0x48)
> [<8011f71c>] (warn_slowpath_null) from [<805a476c>] (brcmu_pkt_buf_free_skb+0x3c/0x40)
> [<805a476c>] (brcmu_pkt_buf_free_skb) from [<805bb6c4>] (brcmf_fws_cleanup+0x1e4/0x22c)
> [<805bb6c4>] (brcmf_fws_cleanup) from [<805bc854>] (brcmf_fws_del_interface+0x58/0x68)
> [<805bc854>] (brcmf_fws_del_interface) from [<805b66ac>] (brcmf_remove_interface+0x40/0x150)
> [<805b66ac>] (brcmf_remove_interface) from [<805b6870>] (brcmf_detach+0x6c/0xb0)
> [<805b6870>] (brcmf_detach) from [<805bdbb8>] (brcmf_usb_disconnect+0x30/0x4c)
> [<805bdbb8>] (brcmf_usb_disconnect) from [<805e5d64>] (usb_unbind_interface+0x5c/0x1e0)
> [<805e5d64>] (usb_unbind_interface) from [<804aab10>] (device_release_driver_internal+0x154/0x1ec)
> [<804aab10>] (device_release_driver_internal) from [<804a97f4>] (bus_remove_device+0xcc/0xf8)
> [<804a97f4>] (bus_remove_device) from [<804a6fc0>] (device_del+0x118/0x308)
> [<804a6fc0>] (device_del) from [<805e488c>] (usb_disable_device+0xa0/0x1c8)
> [<805e488c>] (usb_disable_device) from [<805dcf98>] (usb_disconnect+0x70/0x1d8)
> [<805dcf98>] (usb_disconnect) from [<805ddd84>] (hub_event+0x464/0xf50)
> [<805ddd84>] (hub_event) from [<80135a70>] (process_one_work+0x138/0x3f8)
> [<80135a70>] (process_one_work) from [<80135d5c>] (worker_thread+0x2c/0x554)
> [<80135d5c>] (worker_thread) from [<8013b1a0>] (kthread+0x124/0x154)
> [<8013b1a0>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c)
> Exception stack(0xecf8dfb0 to 0xecf8dff8)
> dfa0: 00000000 00000000 00000000 00000000
> dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> ---[ end trace 38d234018e9e2a90 ]---
> ------------[ cut here ]------------
>
> Signed-off-by: Piotr Figiel <p.figiel@camlintechnologies.com>
2 patches applied to wireless-drivers-next.git, thanks.
c80d26e81ef1 brcmfmac: fix WARNING during USB disconnect in case of unempty psq
5cdb0ef6144f brcmfmac: fix NULL pointer derefence during USB disconnect
--
https://patchwork.kernel.org/patch/10837981/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/4] brcmfmac: support repeated brcmf_fw_alloc_request() calls
From: Kalle Valo @ 2019-04-04 10:00 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, Rafał Miłecki
In-Reply-To: <20190226131119.7907-2-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> During a normal brcmfmac lifetime brcmf_fw_alloc_request() is called
> once only during the probe. It's safe to assume provided array is clear.
>
> Further brcmfmac improvements may require calling it multiple times
> though. This patch allows it by fixing invalid firmware paths like:
> brcm/brcmfmac4366c-pcie.binbrcm/brcmfmac4366c-pcie.bin
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
3 patches applied to wireless-drivers-next.git, thanks.
c9692820710f brcmfmac: support repeated brcmf_fw_alloc_request() calls
a2ec87ddbf16 brcmfmac: add a function designated for handling firmware fails
4684997d9eea brcmfmac: reset PCIe bus on a firmware crash
--
https://patchwork.kernel.org/patch/10830169/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 01/14] qtnfmac: make regulatory notifier work on per-phy basis
From: Kalle Valo @ 2019-04-04 9:58 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: linux-wireless@vger.kernel.org, Igor Mitsyanko,
Sergey Matyukevich
In-Reply-To: <20190320100340.14168-2-sergey.matyukevich.os@quantenna.com>
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> wrote:
> From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
>
> Wireless core calls regulatory notifier for each wiphy and it only
> guarantees that bands info is updated for this particular wiphy prior
> to calling a notifier. Hence updating all wiphy which belong to driver
> in a single notifier callback is redundant and incorrect.
>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
13 patches applied to wireless-drivers-next.git, thanks.
d123172175db qtnfmac: make regulatory notifier work on per-phy basis
642f15a5cee7 qtnfmac: simplify error reporting in regulatory notifier
a2fbaaf757e3 qtnfmac: include full channels info to regulatory notifier
2c31129f8f40 qtnfmac: pass complete channel info in regulatory notifier
48cefdfbcb57 qtnfmac: flexible regulatory domain registration logic
c698bce01562 qtnfmac: allow each MAC to specify its own regulatory rules
438fb43bcab1 qtnfmac: pass DFS region to firmware on region update
93eeab26791d qtnfmac: update bands information on CHANGE_INTF command
ae1946be26bc qtnfmac: fix core attach error path in pcie backend
83b00f6eb863 qtnfmac: simplify firmware state tracking
72b3270e01ab qtnfmac: allow changing the netns
bc70732f9bd9 qtnfmac: send EAPOL frames via control path
b63967cae6b1 qtnfmac: use scan duration param for different scan types
--
https://patchwork.kernel.org/patch/10861235/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH v2 06/13] iwlwifi: dbg_ini: add debug prints to the ini flows
From: Luca Coelho @ 2019-04-04 8:58 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Shahar S Matityahu, Luca Coelho
In-Reply-To: <20190403092224.815-7-luca@coelho.fi>
From: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Add debug prints to the ini flow and rewrite existing prints to provide
more information
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 102 ++++++++++++++----
.../net/wireless/intel/iwlwifi/iwl-dbg-tlv.c | 2 +-
.../net/wireless/intel/iwlwifi/pcie/trans.c | 2 +
3 files changed, 82 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
index ad8a5411212e..2762b8853e72 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
+++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
@@ -1685,6 +1685,9 @@ iwl_dump_ini_mem(struct iwl_fw_runtime *fwrt,
!ops->fill_mem_hdr || !ops->fill_range))
return;
+ IWL_DEBUG_FW(fwrt, "WRT: collecting region: id=%d, type=%d\n",
+ le32_to_cpu(reg->region_id), type);
+
num_of_ranges = ops->get_num_of_ranges(fwrt, reg);
(*data)->type = cpu_to_le32(type | INI_DUMP_BIT);
@@ -1698,7 +1701,8 @@ iwl_dump_ini_mem(struct iwl_fw_runtime *fwrt,
range = ops->fill_mem_hdr(fwrt, reg, header);
if (!range) {
- IWL_ERR(fwrt, "Failed to fill region header: id=%d, type=%d\n",
+ IWL_ERR(fwrt,
+ "WRT: failed to fill region header: id=%d, type=%d\n",
le32_to_cpu(reg->region_id), type);
return;
}
@@ -1707,7 +1711,8 @@ iwl_dump_ini_mem(struct iwl_fw_runtime *fwrt,
int range_size = ops->fill_range(fwrt, reg, range, i);
if (range_size < 0) {
- IWL_ERR(fwrt, "Failed to dump region: id=%d, type=%d\n",
+ IWL_ERR(fwrt,
+ "WRT: failed to dump region: id=%d, type=%d\n",
le32_to_cpu(reg->region_id), type);
return;
}
@@ -1732,8 +1737,12 @@ static int iwl_fw_ini_get_trigger_len(struct iwl_fw_runtime *fwrt,
continue;
reg = fwrt->dump.active_regs[reg_id];
- if (WARN(!reg, "Unassigned region %d\n", reg_id))
+ if (!reg) {
+ IWL_WARN(fwrt,
+ "WRT: unassigned region id %d, skipping\n",
+ reg_id);
continue;
+ }
switch (le32_to_cpu(reg->region_type)) {
case IWL_FW_INI_REGION_DEVICE_MEMORY:
@@ -2110,6 +2119,12 @@ int _iwl_fw_dbg_ini_collect(struct iwl_fw_runtime *fwrt,
if (test_and_set_bit(IWL_FWRT_STATUS_DUMPING, &fwrt->status))
return -EBUSY;
+ if (!iwl_fw_ini_trigger_on(fwrt, id)) {
+ IWL_WARN(fwrt, "WRT: Trigger %d is not active, aborting dump\n",
+ id);
+ return -EINVAL;
+ }
+
active = &fwrt->dump.active_trigs[id];
delay = le32_to_cpu(active->trig->dump_delay);
occur = le32_to_cpu(active->trig->occurrences);
@@ -2119,14 +2134,14 @@ int _iwl_fw_dbg_ini_collect(struct iwl_fw_runtime *fwrt,
active->trig->occurrences = cpu_to_le32(--occur);
if (le32_to_cpu(active->trig->force_restart)) {
- IWL_WARN(fwrt, "Force restart: trigger %d fired.\n", id);
+ IWL_WARN(fwrt, "WRT: force restart: trigger %d fired.\n", id);
iwl_force_nmi(fwrt->trans);
return 0;
}
fwrt->dump.ini_trig_id = id;
- IWL_WARN(fwrt, "Collecting data: ini trigger %d fired.\n", id);
+ IWL_WARN(fwrt, "WRT: collecting data: ini trigger %d fired.\n", id);
schedule_delayed_work(&fwrt->dump.wk, usecs_to_jiffies(delay));
@@ -2264,12 +2279,12 @@ void iwl_fw_dbg_collect_sync(struct iwl_fw_runtime *fwrt)
iwl_fw_dbg_stop_recording(fwrt, ¶ms);
- IWL_DEBUG_INFO(fwrt, "WRT dump start\n");
+ IWL_DEBUG_FW_INFO(fwrt, "WRT: data collection start\n");
if (fwrt->trans->ini_valid)
iwl_fw_error_ini_dump(fwrt);
else
iwl_fw_error_dump(fwrt);
- IWL_DEBUG_INFO(fwrt, "WRT dump done\n");
+ IWL_DEBUG_FW_INFO(fwrt, "WRT: data collection done\n");
/* start recording again if the firmware is not crashed */
if (!test_bit(STATUS_FW_ERROR, &fwrt->trans->status) &&
@@ -2339,12 +2354,14 @@ iwl_fw_dbg_buffer_allocation(struct iwl_fw_runtime *fwrt, u32 size)
if (!virtual_addr)
IWL_ERR(fwrt, "Failed to allocate debug memory\n");
+ IWL_DEBUG_FW(trans,
+ "Allocated DRAM buffer[%d], size=0x%x\n",
+ trans->num_blocks, size);
+
trans->fw_mon[trans->num_blocks].block = virtual_addr;
trans->fw_mon[trans->num_blocks].physical = phys_addr;
trans->fw_mon[trans->num_blocks].size = size;
trans->num_blocks++;
-
- IWL_DEBUG_FW(trans, "Allocated debug block of size %d\n", size);
}
static void iwl_fw_dbg_buffer_apply(struct iwl_fw_runtime *fwrt,
@@ -2367,11 +2384,15 @@ static void iwl_fw_dbg_buffer_apply(struct iwl_fw_runtime *fwrt,
if (buf_location == IWL_FW_INI_LOCATION_SRAM_PATH) {
if (!WARN(pnt != IWL_FW_INI_APPLY_EARLY,
- "Invalid apply point %d for SMEM buffer allocation",
- pnt))
+ "WRT: Invalid apply point %d for SMEM buffer allocation, aborting\n",
+ pnt)) {
+ IWL_DEBUG_FW(trans,
+ "WRT: applying SMEM buffer destination\n");
+
/* set sram monitor by enabling bit 7 */
iwl_set_bit(fwrt->trans, CSR_HW_IF_CONFIG_REG,
CSR_HW_IF_CONFIG_REG_BIT_MONITOR_SRAM);
+ }
return;
}
@@ -2390,6 +2411,9 @@ static void iwl_fw_dbg_buffer_apply(struct iwl_fw_runtime *fwrt,
if (trans->num_blocks == 1)
return;
+ IWL_DEBUG_FW(trans,
+ "WRT: applying DRAM buffer[%d] destination\n", block_idx);
+
cmd->num_frags = cpu_to_le32(1);
cmd->fragments[0].address =
cpu_to_le64(trans->fw_mon[block_idx].physical);
@@ -2401,7 +2425,8 @@ static void iwl_fw_dbg_buffer_apply(struct iwl_fw_runtime *fwrt,
}
static void iwl_fw_dbg_send_hcmd(struct iwl_fw_runtime *fwrt,
- struct iwl_ucode_tlv *tlv)
+ struct iwl_ucode_tlv *tlv,
+ bool ext)
{
struct iwl_fw_ini_hcmd_tlv *hcmd_tlv = (void *)&tlv->data[0];
struct iwl_fw_ini_hcmd *data = &hcmd_tlv->hcmd;
@@ -2417,6 +2442,10 @@ static void iwl_fw_dbg_send_hcmd(struct iwl_fw_runtime *fwrt,
if (le32_to_cpu(hcmd_tlv->domain) != IWL_FW_INI_DBG_DOMAIN_ALWAYS_ON)
return;
+ IWL_DEBUG_FW(fwrt,
+ "WRT: ext=%d. Sending host command id=0x%x, group=0x%x\n",
+ ext, data->id, data->group);
+
iwl_trans_send_cmd(fwrt->trans, &hcmd);
}
@@ -2433,17 +2462,20 @@ static void iwl_fw_dbg_update_regions(struct iwl_fw_runtime *fwrt,
u32 type = le32_to_cpu(reg->region_type);
if (WARN(id >= ARRAY_SIZE(fwrt->dump.active_regs),
- "Invalid region id %d for apply point %d\n", id, pnt))
+ "WRT: ext=%d. Invalid region id %d for apply point %d\n",
+ ext, id, pnt))
break;
active = &fwrt->dump.active_regs[id];
if (*active)
- IWL_WARN(fwrt->trans, "region TLV %d override\n", id);
+ IWL_WARN(fwrt->trans,
+ "WRT: ext=%d. Region id %d override\n",
+ ext, id);
IWL_DEBUG_FW(fwrt,
- "%s: apply point %d, activating region ID %d\n",
- __func__, pnt, id);
+ "WRT: ext=%d. Activating region id %d\n",
+ ext, id);
*active = reg;
@@ -2476,7 +2508,8 @@ static int iwl_fw_dbg_trig_realloc(struct iwl_fw_runtime *fwrt,
ptr = krealloc(active->trig, size, GFP_KERNEL);
if (!ptr) {
- IWL_ERR(fwrt, "Failed to allocate memory for trigger %d\n", id);
+ IWL_ERR(fwrt, "WRT: Failed to allocate memory for trigger %d\n",
+ id);
return -ENOMEM;
}
active->trig = ptr;
@@ -2500,7 +2533,9 @@ static void iwl_fw_dbg_update_triggers(struct iwl_fw_runtime *fwrt,
u32 trig_regs_size = le32_to_cpu(trig->num_regions) *
sizeof(__le32);
- if (WARN_ON(id >= ARRAY_SIZE(fwrt->dump.active_trigs)))
+ if (WARN(id >= ARRAY_SIZE(fwrt->dump.active_trigs),
+ "WRT: ext=%d. Invalid trigger id %d for apply point %d\n",
+ ext, id, apply_point))
break;
active = &fwrt->dump.active_trigs[id];
@@ -2508,6 +2543,10 @@ static void iwl_fw_dbg_update_triggers(struct iwl_fw_runtime *fwrt,
if (!active->active) {
size_t trig_size = sizeof(*trig) + trig_regs_size;
+ IWL_DEBUG_FW(fwrt,
+ "WRT: ext=%d. Activating trigger %d\n",
+ ext, id);
+
if (iwl_fw_dbg_trig_realloc(fwrt, active, id,
trig_size))
goto next;
@@ -2526,8 +2565,16 @@ static void iwl_fw_dbg_update_triggers(struct iwl_fw_runtime *fwrt,
int mem_to_add = trig_regs_size;
if (region_override) {
+ IWL_DEBUG_FW(fwrt,
+ "WRT: ext=%d. Trigger %d regions override\n",
+ ext, id);
+
mem_to_add -= active_regs * sizeof(__le32);
} else {
+ IWL_DEBUG_FW(fwrt,
+ "WRT: ext=%d. Trigger %d regions appending\n",
+ ext, id);
+
offset += active_regs;
new_regs += active_regs;
}
@@ -2536,8 +2583,13 @@ static void iwl_fw_dbg_update_triggers(struct iwl_fw_runtime *fwrt,
active->size + mem_to_add))
goto next;
- if (conf_override)
+ if (conf_override) {
+ IWL_DEBUG_FW(fwrt,
+ "WRT: ext=%d. Trigger %d configuration override\n",
+ ext, id);
+
memcpy(active->trig, trig, sizeof(*trig));
+ }
memcpy(active->trig->data + offset, trig->data,
trig_regs_size);
@@ -2578,11 +2630,11 @@ static void _iwl_fw_dbg_apply_point(struct iwl_fw_runtime *fwrt,
case IWL_UCODE_TLV_TYPE_HCMD:
if (pnt < IWL_FW_INI_APPLY_AFTER_ALIVE) {
IWL_ERR(fwrt,
- "Invalid apply point %x for host command\n",
- pnt);
+ "WRT: ext=%d. Invalid apply point %d for host command\n",
+ ext, pnt);
goto next;
}
- iwl_fw_dbg_send_hcmd(fwrt, tlv);
+ iwl_fw_dbg_send_hcmd(fwrt, tlv, ext);
break;
case IWL_UCODE_TLV_TYPE_REGIONS:
iwl_fw_dbg_update_regions(fwrt, ini_tlv, ext, pnt);
@@ -2593,7 +2645,9 @@ static void _iwl_fw_dbg_apply_point(struct iwl_fw_runtime *fwrt,
case IWL_UCODE_TLV_TYPE_DEBUG_FLOW:
break;
default:
- WARN_ONCE(1, "Invalid TLV %x for apply point\n", type);
+ WARN_ONCE(1,
+ "WRT: ext=%d. Invalid TLV 0x%x for apply point\n",
+ ext, type);
break;
}
next:
@@ -2607,6 +2661,8 @@ void iwl_fw_dbg_apply_point(struct iwl_fw_runtime *fwrt,
void *data = &fwrt->trans->apply_points[apply_point];
int i;
+ IWL_DEBUG_FW(fwrt, "WRT: enabling apply point %d\n", apply_point);
+
if (apply_point == IWL_FW_INI_APPLY_EARLY) {
for (i = 0; i < IWL_FW_INI_MAX_REGION_ID; i++)
fwrt->dump.active_regs[i] = NULL;
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c b/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c
index 9107302cc444..08e40a8f9f6b 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c
@@ -138,7 +138,7 @@ void iwl_alloc_dbg_tlv(struct iwl_trans *trans, size_t len, const u8 *data,
if (le32_to_cpu(hdr->tlv_version) != 1)
continue;
- IWL_DEBUG_FW(trans, "Read TLV %x, apply point %d\n",
+ IWL_DEBUG_FW(trans, "WRT: read TLV 0x%x, apply point %d\n",
le32_to_cpu(tlv->type), apply);
if (WARN_ON(apply >= IWL_FW_INI_APPLY_NUM))
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index cfaad360c823..ce71ac662ad0 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -896,6 +896,8 @@ void iwl_pcie_apply_destination(struct iwl_trans *trans)
if (!trans->num_blocks)
return;
+ IWL_DEBUG_FW(trans,
+ "WRT: applying DRAM buffer[0] destination\n");
iwl_write_umac_prph(trans, MON_BUFF_BASE_ADDR_VER2,
trans->fw_mon[0].physical >>
MON_BUFF_SHIFT_VER2);
--
2.20.1
^ permalink raw reply related
* [PATCH 4.19 049/187] mt76: fix a leaked reference by adding a missing of_node_put
From: Greg Kroah-Hartman @ 2019-04-04 8:46 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Wen Yang, Felix Fietkau,
Lorenzo Bianconi, Kalle Valo, David S. Miller, Matthias Brugger,
linux-wireless, netdev, linux-arm-kernel, linux-mediatek,
Sasha Levin
In-Reply-To: <20190404084603.119654039@linuxfoundation.org>
4.19-stable review patch. If anyone has any objections, please let me know.
------------------
[ Upstream commit 34e022d8b780a03902d82fb3997ba7c7b1f40c81 ]
The call to of_find_node_by_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./drivers/net/wireless/mediatek/mt76/eeprom.c:58:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:61:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:67:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:70:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:72:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Felix Fietkau <nbd@nbd.name>
Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/eeprom.c | 24 ++++++++++++++-------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
index 530e5593765c..a1529920d877 100644
--- a/drivers/net/wireless/mediatek/mt76/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
@@ -54,22 +54,30 @@ mt76_get_of_eeprom(struct mt76_dev *dev, int len)
part = np->name;
mtd = get_mtd_device_nm(part);
- if (IS_ERR(mtd))
- return PTR_ERR(mtd);
+ if (IS_ERR(mtd)) {
+ ret = PTR_ERR(mtd);
+ goto out_put_node;
+ }
- if (size <= sizeof(*list))
- return -EINVAL;
+ if (size <= sizeof(*list)) {
+ ret = -EINVAL;
+ goto out_put_node;
+ }
offset = be32_to_cpup(list);
ret = mtd_read(mtd, offset, len, &retlen, dev->eeprom.data);
put_mtd_device(mtd);
if (ret)
- return ret;
+ goto out_put_node;
- if (retlen < len)
- return -EINVAL;
+ if (retlen < len) {
+ ret = -EINVAL;
+ goto out_put_node;
+ }
- return 0;
+out_put_node:
+ of_node_put(np);
+ return ret;
#else
return -ENOENT;
#endif
--
2.19.1
^ permalink raw reply related
* [PATCH 5.0 060/246] mt76: fix a leaked reference by adding a missing of_node_put
From: Greg Kroah-Hartman @ 2019-04-04 8:46 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Wen Yang, Felix Fietkau,
Lorenzo Bianconi, Kalle Valo, David S. Miller, Matthias Brugger,
linux-wireless, netdev, linux-arm-kernel, linux-mediatek,
Sasha Levin
In-Reply-To: <20190404084619.236418459@linuxfoundation.org>
5.0-stable review patch. If anyone has any objections, please let me know.
------------------
[ Upstream commit 34e022d8b780a03902d82fb3997ba7c7b1f40c81 ]
The call to of_find_node_by_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./drivers/net/wireless/mediatek/mt76/eeprom.c:58:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:61:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:67:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:70:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
./drivers/net/wireless/mediatek/mt76/eeprom.c:72:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 48, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Felix Fietkau <nbd@nbd.name>
Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/eeprom.c | 24 ++++++++++++++-------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
index 530e5593765c..a1529920d877 100644
--- a/drivers/net/wireless/mediatek/mt76/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
@@ -54,22 +54,30 @@ mt76_get_of_eeprom(struct mt76_dev *dev, int len)
part = np->name;
mtd = get_mtd_device_nm(part);
- if (IS_ERR(mtd))
- return PTR_ERR(mtd);
+ if (IS_ERR(mtd)) {
+ ret = PTR_ERR(mtd);
+ goto out_put_node;
+ }
- if (size <= sizeof(*list))
- return -EINVAL;
+ if (size <= sizeof(*list)) {
+ ret = -EINVAL;
+ goto out_put_node;
+ }
offset = be32_to_cpup(list);
ret = mtd_read(mtd, offset, len, &retlen, dev->eeprom.data);
put_mtd_device(mtd);
if (ret)
- return ret;
+ goto out_put_node;
- if (retlen < len)
- return -EINVAL;
+ if (retlen < len) {
+ ret = -EINVAL;
+ goto out_put_node;
+ }
- return 0;
+out_put_node:
+ of_node_put(np);
+ return ret;
#else
return -ENOENT;
#endif
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v2] net: mwifiex: fix a NULL pointer dereference
From: Kalle Valo @ 2019-04-04 9:28 UTC (permalink / raw)
To: Kangjie Lu
Cc: kjlu, pakki001, Amitkumar Karwar, Nishant Sarmukadam,
Ganapathi Bhat, Xinming Hu, David S. Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20190323035711.23882-1-kjlu@umn.edu>
Kangjie Lu <kjlu@umn.edu> wrote:
> In case dev_alloc_skb fails, the fix returns -ENOMEM to avoid
> NULL pointer dereference.
>
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>
There is a similar patch submitted:
https://patchwork.kernel.org/patch/10851669/
Patch set to Superseded.
--
https://patchwork.kernel.org/patch/10866749/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH] ath6kl: add some bounds checking
From: Dan Carpenter @ 2019-04-04 8:56 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, kernel-janitors
The "ev->traffic_class" and "reply->ac" variables come from the network
and they're used as an offset into the wmi->stream_exist_for_ac[] array.
Those variables are u8 so they can be 0-255 but the stream_exist_for_ac[]
array only has WMM_NUM_AC (4) elements. We need to add a couple bounds
checks to prevent array overflows.
I also modified one existing check from "if (traffic_class > 3) {" to
"if (traffic_class >= WMM_NUM_AC) {" just to make them all consistent.
Fixes: bdcd81707973 (" Add ath6kl cleaned up driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
drivers/net/wireless/ath/ath6kl/wmi.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c b/drivers/net/wireless/ath/ath6kl/wmi.c
index 68854c45d0a4..9ab6aa9ded5c 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -1176,6 +1176,10 @@ static int ath6kl_wmi_pstream_timeout_event_rx(struct wmi *wmi, u8 *datap,
return -EINVAL;
ev = (struct wmi_pstream_timeout_event *) datap;
+ if (ev->traffic_class >= WMM_NUM_AC) {
+ ath6kl_err("invalid traffic class: %d\n", ev->traffic_class);
+ return -EINVAL;
+ }
/*
* When the pstream (fat pipe == AC) timesout, it means there were
@@ -1517,6 +1521,10 @@ static int ath6kl_wmi_cac_event_rx(struct wmi *wmi, u8 *datap, int len,
return -EINVAL;
reply = (struct wmi_cac_event *) datap;
+ if (reply->ac >= WMM_NUM_AC) {
+ ath6kl_err("invalid AC: %d\n", reply->ac);
+ return -EINVAL;
+ }
if ((reply->cac_indication == CAC_INDICATION_ADMISSION_RESP) &&
(reply->status_code != IEEE80211_TSPEC_STATUS_ADMISS_ACCEPTED)) {
@@ -2633,7 +2641,7 @@ int ath6kl_wmi_delete_pstream_cmd(struct wmi *wmi, u8 if_idx, u8 traffic_class,
u16 active_tsids = 0;
int ret;
- if (traffic_class > 3) {
+ if (traffic_class >= WMM_NUM_AC) {
ath6kl_err("invalid traffic class: %d\n", traffic_class);
return -EINVAL;
}
--
2.17.1
^ permalink raw reply related
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