* Re: [PATCH 3/7] brcmsmac: switch source files to using SPDX license identifier
From: Kalle Valo @ 2019-05-23 9:16 UTC (permalink / raw)
To: Arend van Spriel
Cc: linux-wireless, Arend van Spriel, Thomas Gleixner,
Greg Kroah-Hartman
In-Reply-To: <1558008251-13692-4-git-send-email-arend.vanspriel@broadcom.com>
Arend van Spriel <arend.vanspriel@broadcom.com> wrote:
> With ISC license text in place under the LICENSES folder switch
> to using the SPDX license identifier to refer to the ISC license.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 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>
Dropped per discussion
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/10946471/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] wireless: fix intel typos in code comments
From: Kalle Valo @ 2019-05-23 9:14 UTC (permalink / raw)
To: Weitao Hou; +Cc: stas.yakovlev, davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20190519033114.20271-1-houweitaoo@gmail.com>
Weitao Hou <houweitaoo@gmail.com> writes:
> fix lengh to length
>
> Signed-off-by: Weitao Hou <houweitaoo@gmail.com>
> ---
> drivers/net/wireless/intel/ipw2x00/ipw2200.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Correct prefix is "ipw2x00:".
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] net: fix typos in code comments
From: Kalle Valo @ 2019-05-23 9:12 UTC (permalink / raw)
To: Weitao Hou
Cc: nbd, lorenzo.bianconi83, ryder.lee, royluo, davem, matthias.bgg,
linux-wireless, netdev, linux-arm-kernel, linux-mediatek,
linux-kernel
In-Reply-To: <20190519030923.18343-1-houweitaoo@gmail.com>
Weitao Hou <houweitaoo@gmail.com> writes:
> fix lenght to length
>
> Signed-off-by: Weitao Hou <houweitaoo@gmail.com>
> ---
> drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c | 2 +-
Please use correct prefix "mt76:":
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] rsi: Properly initialize data in rsi_sdio_ta_reset
From: Kalle Valo @ 2019-05-23 8:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Nathan Chancellor, Nick Desaulniers, Amitkumar Karwar,
Siva Rebbagondla, linux-wireless, Networking, LKML,
clang-built-linux
In-Reply-To: <CAK8P3a001V5qQo4vGfpugtmrnFfUNeP_q4KY-YS7rP_L91HY1A@mail.gmail.com>
Arnd Bergmann <arnd@arndb.de> writes:
>> > @@ -937,7 +937,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
>> > }
>> >
>> > rsi_dbg(INIT_ZONE, "%s: Bring TA out of reset\n", __func__);
>> > - put_unaligned_le32(TA_HOLD_THREAD_VALUE, data);
>> > + put_unaligned_le32(TA_HOLD_THREAD_VALUE, &data);
>> > addr = TA_HOLD_THREAD_REG | RSI_SD_REQUEST_MASTER;
>> > status = rsi_sdio_write_register_multiple(adapter, addr,
>> > (u8 *)&data,
>
> This is clearly not ok, as put_unaligned_le32() stores four bytes, and
> the local variable is only one byte!
>
> Also, sdio does use DMA for transfers, so the variable has to be
> dynamically allocated. I think your original patch was correct.
> The only change I'd possibly make would be to use
> RSI_9116_REG_SIZE instead of sizeof(u32).
Good point. Nathan please fix this and submit v2.
>> Did any of the maintainers have any comments on what the correct
>> solution is here to resolve this warning? It is one of the few left
>> before we can turn on -Wuninitialized for the whole kernel.
>
> I would argue that this should not stop us from turning it on, as the
> warning is for a clear bug in the code that absolutely needs to be
> fixed, rather than a false-positive.
I can queue v2 for v5.2, just remind me by adding "[PATCH v2 5.2]" to
the subject.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v3] ath10k: add support for firmware crash recovery on SDIO chip
From: Claire Chang @ 2019-05-23 8:53 UTC (permalink / raw)
To: Wen Gong; +Cc: ath10k, open list:NETWORKING DRIVERS (WIRELESS)
In-Reply-To: <1558506776-19702-1-git-send-email-wgong@codeaurora.org>
Tested-by: Claire Chang <tientzu@chromium.org>
^ permalink raw reply
* Re: [PATCH] rsi: Properly initialize data in rsi_sdio_ta_reset
From: Kalle Valo @ 2019-05-23 8:52 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Nick Desaulniers, Amitkumar Karwar, Siva Rebbagondla,
linux-wireless, netdev, LKML, clang-built-linux
In-Reply-To: <20190523015415.GA17819@archlinux-epyc>
Nathan Chancellor <natechancellor@gmail.com> writes:
> On Thu, May 02, 2019 at 08:17:18PM -0700, Nathan Chancellor wrote:
>> On Thu, May 02, 2019 at 11:18:01AM -0700, Nick Desaulniers wrote:
>> > On Thu, May 2, 2019 at 8:16 AM Nathan Chancellor
>> > <natechancellor@gmail.com> wrote:
>> > >
>> > > When building with -Wuninitialized, Clang warns:
>> > >
>> > > drivers/net/wireless/rsi/rsi_91x_sdio.c:940:43: warning: variable 'data'
>> > > is uninitialized when used here [-Wuninitialized]
>> > > put_unaligned_le32(TA_HOLD_THREAD_VALUE, data);
>> > > ^~~~
>> > > drivers/net/wireless/rsi/rsi_91x_sdio.c:930:10: note: initialize the
>> > > variable 'data' to silence this warning
>> > > u8 *data;
>> > > ^
>> > > = NULL
>> > > 1 warning generated.
>> > >
>> > > Using Clang's suggestion of initializing data to NULL wouldn't work out
>> > > because data will be dereferenced by put_unaligned_le32. Use kzalloc to
>> > > properly initialize data, which matches a couple of other places in this
>> > > driver.
>> > >
>> > > Fixes: e5a1ecc97e5f ("rsi: add firmware loading for 9116 device")
>> > > Link: https://github.com/ClangBuiltLinux/linux/issues/464
>> > > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>> > > ---
>> > > drivers/net/wireless/rsi/rsi_91x_sdio.c | 21 ++++++++++++++-------
>> > > 1 file changed, 14 insertions(+), 7 deletions(-)
>> > >
>> > > diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c
>> > > index f9c67ed473d1..b35728564c7b 100644
>> > > --- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
>> > > +++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
>> > > @@ -929,11 +929,15 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
>> > > u32 addr;
>> > > u8 *data;
>> > >
>> > > + data = kzalloc(sizeof(u32), GFP_KERNEL);
>> >
>> > Something fishy is going on here. We allocate 4 B but declare data as
>> > a u8* (pointer to individual bytes)? In general, dynamically
>> > allocating that few bytes is a code smell; either you meant to just
>> > use the stack, or this memory's lifetime extends past the lifetime of
>> > this stackframe, at which point you probably just meant to stack
>> > allocate space in a higher parent frame and pass this preallocated
>> > memory down to the child frame to get filled in.
>> >
>> > Reading through this code, I don't think that the memory is meant to
>> > outlive the stack frame. Is there a reason why we can't just declare
>> > data as:
>> >
>> > u8 data [4];
>>
>> data was __le32 in rsi_reset_chip() before commit f700546682a6 ("rsi:
>> fix nommu_map_sg overflow kernel panic").
>>
>> I wonder if this would be okay for this function:
>>
>> -------------------------------------------------
>>
>> diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c
>> index f9c67ed473d1..0330c50ab99c 100644
>> --- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
>> +++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
>> @@ -927,7 +927,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
>> {
>> int status;
>> u32 addr;
>> - u8 *data;
>> + u8 data;
>>
>> status = rsi_sdio_master_access_msword(adapter, TA_BASE_ADDR);
>> if (status < 0) {
>> @@ -937,7 +937,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
>> }
>>
>> rsi_dbg(INIT_ZONE, "%s: Bring TA out of reset\n", __func__);
>> - put_unaligned_le32(TA_HOLD_THREAD_VALUE, data);
>> + put_unaligned_le32(TA_HOLD_THREAD_VALUE, &data);
>> addr = TA_HOLD_THREAD_REG | RSI_SD_REQUEST_MASTER;
>> status = rsi_sdio_write_register_multiple(adapter, addr,
>> (u8 *)&data,
>> @@ -947,7 +947,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
>> return status;
>> }
>>
>> - put_unaligned_le32(TA_SOFT_RST_CLR, data);
>> + put_unaligned_le32(TA_SOFT_RST_CLR, &data);
>> addr = TA_SOFT_RESET_REG | RSI_SD_REQUEST_MASTER;
>> status = rsi_sdio_write_register_multiple(adapter, addr,
>> (u8 *)&data,
>> @@ -957,7 +957,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
>> return status;
>> }
>>
>> - put_unaligned_le32(TA_PC_ZERO, data);
>> + put_unaligned_le32(TA_PC_ZERO, &data);
>> addr = TA_TH0_PC_REG | RSI_SD_REQUEST_MASTER;
>> status = rsi_sdio_write_register_multiple(adapter, addr,
>> (u8 *)&data,
>> @@ -967,7 +967,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
>> return -EINVAL;
>> }
>>
>> - put_unaligned_le32(TA_RELEASE_THREAD_VALUE, data);
>> + put_unaligned_le32(TA_RELEASE_THREAD_VALUE, &data);
>> addr = TA_RELEASE_THREAD_REG | RSI_SD_REQUEST_MASTER;
>> status = rsi_sdio_write_register_multiple(adapter, addr,
>> (u8 *)&data,
>>
>>
>> >
>> > then use ARRAY_SIZE(data) or RSI_9116_REG_SIZE in rsi_reset_chip(),
>> > getting rid of the kzalloc/kfree?
>> >
>> > (Sorry, I hate when a simple fixup becomes a "hey let's rewrite all
>> > this code" thus becoming "that guy.")
>>
>> If we aren't actually improving the code, then why bother? :)
>>
>> Thank you for the review!
>
> Did any of the maintainers have any comments on what the correct
> solution is here to resolve this warning? It is one of the few left
> before we can turn on -Wuninitialized for the whole kernel.
I don't have any strong opinion, but as the commit log says that
kzalloc() is also used in similar cases in the same driver I would happy
to take this patch as is.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] rsi: Properly initialize data in rsi_sdio_ta_reset
From: Arnd Bergmann @ 2019-05-23 8:51 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Nick Desaulniers, Amitkumar Karwar, Siva Rebbagondla, Kalle Valo,
linux-wireless, Networking, LKML, clang-built-linux
In-Reply-To: <20190523015415.GA17819@archlinux-epyc>
On Thu, May 23, 2019 at 3:54 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> On Thu, May 02, 2019 at 08:17:18PM -0700, Nathan Chancellor wrote:
> > On Thu, May 02, 2019 at 11:18:01AM -0700, Nick Desaulniers wrote:
> > > On Thu, May 2, 2019 at 8:16 AM Nathan Chancellor
> > > u8 data [4];
> >
> > data was __le32 in rsi_reset_chip() before commit f700546682a6 ("rsi:
> > fix nommu_map_sg overflow kernel panic").
> >
> > I wonder if this would be okay for this function:
> >
> > -------------------------------------------------
> >
> > diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c
> > index f9c67ed473d1..0330c50ab99c 100644
> > --- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
> > +++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
> > @@ -927,7 +927,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
> > {
> > int status;
> > u32 addr;
> > - u8 *data;
> > + u8 data;
> >
> > status = rsi_sdio_master_access_msword(adapter, TA_BASE_ADDR);
> > if (status < 0) {
> > @@ -937,7 +937,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
> > }
> >
> > rsi_dbg(INIT_ZONE, "%s: Bring TA out of reset\n", __func__);
> > - put_unaligned_le32(TA_HOLD_THREAD_VALUE, data);
> > + put_unaligned_le32(TA_HOLD_THREAD_VALUE, &data);
> > addr = TA_HOLD_THREAD_REG | RSI_SD_REQUEST_MASTER;
> > status = rsi_sdio_write_register_multiple(adapter, addr,
> > (u8 *)&data,
This is clearly not ok, as put_unaligned_le32() stores four bytes, and
the local variable is only one byte!
Also, sdio does use DMA for transfers, so the variable has to be
dynamically allocated. I think your original patch was correct.
The only change I'd possibly make would be to use
RSI_9116_REG_SIZE instead of sizeof(u32).
> Did any of the maintainers have any comments on what the correct
> solution is here to resolve this warning? It is one of the few left
> before we can turn on -Wuninitialized for the whole kernel.
I would argue that this should not stop us from turning it on, as the
warning is for a clear bug in the code that absolutely needs to be
fixed, rather than a false-positive.
Arnd
^ permalink raw reply
* [PATCH V2] mac80211: fix rate reporting inside cfg80211_calculate_bitrate_he()
From: John Crispin @ 2019-05-23 8:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin, Shashidhar Lakkavalli
The reported rate is not scaled down correctly. After applying this patch,
the function will behave just like the v/ht equivalents.
Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: John Crispin <john@phrozen.org>
---
net/wireless/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 75899b62bdc9..5a03f38788e7 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1237,7 +1237,7 @@ static u32 cfg80211_calculate_bitrate_he(struct rate_info *rate)
if (rate->he_dcm)
result /= 2;
- return result;
+ return result / 10000;
}
u32 cfg80211_calculate_bitrate(struct rate_info *rate)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] mac80211: fix rate reporting inside cfg80211_calculate_bitrate_he()
From: John Crispin @ 2019-05-23 8:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Shashidhar Lakkavalli
In-Reply-To: <20190523080332.29173-1-john@phrozen.org>
On 23/05/2019 10:03, John Crispin wrote:
> The reported rate is not scaled done correctly. After applying this patch, the
> function will behave just like the v/ht equivalents.
s/done/down/ ... sorry aspell obviously did not catch that one :-)
John
> Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
> Signed-off-by: John Crispin <john@phrozen.org>
> ---
> net/wireless/util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/wireless/util.c b/net/wireless/util.c
> index 75899b62bdc9..5a03f38788e7 100644
> --- a/net/wireless/util.c
> +++ b/net/wireless/util.c
> @@ -1237,7 +1237,7 @@ static u32 cfg80211_calculate_bitrate_he(struct rate_info *rate)
> if (rate->he_dcm)
> result /= 2;
>
> - return result;
> + return result / 10000;
> }
>
> u32 cfg80211_calculate_bitrate(struct rate_info *rate)
^ permalink raw reply
* [PATCH] mac80211: fix rate reporting inside cfg80211_calculate_bitrate_he()
From: John Crispin @ 2019-05-23 8:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin, Shashidhar Lakkavalli
The reported rate is not scaled done correctly. After applying this patch, the
function will behave just like the v/ht equivalents.
Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: John Crispin <john@phrozen.org>
---
net/wireless/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 75899b62bdc9..5a03f38788e7 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1237,7 +1237,7 @@ static u32 cfg80211_calculate_bitrate_he(struct rate_info *rate)
if (rate->he_dcm)
result /= 2;
- return result;
+ return result / 10000;
}
u32 cfg80211_calculate_bitrate(struct rate_info *rate)
--
2.20.1
^ permalink raw reply related
* Re: ath10k QCA9377 firmware crashes and fails to recover
From: Kalle Valo @ 2019-05-23 7:35 UTC (permalink / raw)
To: Daniel Drake; +Cc: ath10k, linux-wireless, Endless Linux Upstreaming Team
In-Reply-To: <CAD8Lp45wxQ3vL_ttq-yKYDxscjn2KyJVCx_vJBCn+u8Yc5QtOQ@mail.gmail.com>
Daniel Drake <drake@endlessm.com> writes:
> We are experiencing failures with QCA9377 wifi, using Linux 4.18 and
> Linux 5.0 with the latest firmware version:
>
> ath10k_pci 0000:02:00.0: firmware crashed! (guid
> 54a4649a-1240-4459-9442-9d498c49de79)
> ath10k_pci 0000:02:00.0: qca9377 hw1.1 target 0x05020001 chip_id
> 0x003821ff sub 1a3b:2b31
> ath10k_pci 0000:02:00.0: kconfig debug 0 debugfs 1 tracing 1 dfs 0 testmode 0
> ath10k_pci 0000:02:00.0: firmware ver WLAN.TF.1.0-00002-QCATFSWPZ-5
> api 5 features ignore-otp crc32 c3e0d04f
Is this a regression? For example, have you tried older firmware
versions?
--
Kalle Valo
^ permalink raw reply
* [PATCH] ath10k: add missing error handling
From: Claire Chang @ 2019-05-23 7:15 UTC (permalink / raw)
To: kvalo; +Cc: ath10k, linux-wireless, wgong, Claire Chang
In function ath10k_sdio_mbox_rx_alloc() [sdio.c],
ath10k_sdio_mbox_alloc_rx_pkt() is called without handling the error cases.
This will make the driver think the allocation for skb is successful and
try to access the skb. If we enable failslab, system will easily crash with
NULL pointer dereferencing.
Call trace of CONFIG_FAILSLAB:
ath10k_sdio_irq_handler+0x570/0xa88 [ath10k_sdio]
process_sdio_pending_irqs+0x4c/0x174
sdio_run_irqs+0x3c/0x64
sdio_irq_work+0x1c/0x28
Fixes: d96db25d2025 ("ath10k: add initial SDIO support")
Signed-off-by: Claire Chang <tientzu@chromium.org>
---
drivers/net/wireless/ath/ath10k/sdio.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c
index 9bbd5b54b8ca..4b7f1c6f13e2 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -607,6 +607,10 @@ static int ath10k_sdio_mbox_rx_alloc(struct ath10k *ar,
full_len,
last_in_bundle,
last_in_bundle);
+ if (ret) {
+ ath10k_warn(ar, "alloc_rx_pkt error %d\n", ret);
+ goto err;
+ }
}
ar_sdio->n_rx_pkts = i;
--
2.21.0.1020.gf2820cf01a-goog
^ permalink raw reply related
* ath10k QCA9377 firmware crashes and fails to recover
From: Daniel Drake @ 2019-05-23 3:19 UTC (permalink / raw)
To: Kalle Valo, ath10k; +Cc: linux-wireless, Endless Linux Upstreaming Team
Hi,
We are experiencing failures with QCA9377 wifi, using Linux 4.18 and
Linux 5.0 with the latest firmware version:
ath10k_pci 0000:02:00.0: firmware crashed! (guid
54a4649a-1240-4459-9442-9d498c49de79)
ath10k_pci 0000:02:00.0: qca9377 hw1.1 target 0x05020001 chip_id
0x003821ff sub 1a3b:2b31
ath10k_pci 0000:02:00.0: kconfig debug 0 debugfs 1 tracing 1 dfs 0 testmode 0
ath10k_pci 0000:02:00.0: firmware ver WLAN.TF.1.0-00002-QCATFSWPZ-5
api 5 features ignore-otp crc32 c3e0d04f
ath10k_pci 0000:02:00.0: board_file api 2 bmi_id N/A crc32 8aedfa4a
ath10k_pci 0000:02:00.0: htt-ver 3.44 wmi-op 4 htt-op 3 cal otp
max-sta 32 raw 0 hwcrypto 1
ath10k_pci 0000:02:00.0: firmware register dump:
ath10k_pci 0000:02:00.0: [00]: 0x05020001 0x00000000 0x1D008136 0x00000000
ath10k_pci 0000:02:00.0: [04]: 0x1D008136 0x00060330 0x00000004 0x00000000
ath10k_pci 0000:02:00.0: [08]: 0x00000001 0x0042B0EC 0x0040E84C 0x00433E18
ath10k_pci 0000:02:00.0: [12]: 0x00000000 0xFFFFFFFF 0x00952F6C 0x00952F77
ath10k_pci 0000:02:00.0: [16]: 0x0127099E 0x7DBF8AE8 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [20]: 0x0000013C 0x00433E18 0x0040E7E8 0x00436ED0
ath10k_pci 0000:02:00.0: [24]: 0x800B1A0B 0x0040E7E8 0x00433E18 0x00436FA0
ath10k_pci 0000:02:00.0: [28]: 0x00000001 0x00433E18 0x00436FA0 0x00429558
ath10k_pci 0000:02:00.0: [32]: 0x00000000 0x00433E18 0x00400000 0x000000F4
ath10k_pci 0000:02:00.0: [36]: 0x809ED9B2 0x0040E898 0x00000201 0x0040E900
ath10k_pci 0000:02:00.0: [40]: 0x00800000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [44]: 0x00000000 0x00000000 0x00000001 0x00000000
ath10k_pci 0000:02:00.0: [48]: 0x00000018 0x00436FA0 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [52]: 0x004089D0 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [56]: 0x00000127 0x00000000 0x00000040 0x80168040
ath10k_pci 0000:02:00.0: Copy Engine register dump:
ath10k_pci 0000:02:00.0: [00]: 0x00034400 2 2 3 3
ath10k_pci 0000:02:00.0: [01]: 0x00034800 21 21 98 99
ath10k_pci 0000:02:00.0: [02]: 0x00034c00 12 12 75 76
ath10k_pci 0000:02:00.0: [03]: 0x00035000 7 7 9 7
ath10k_pci 0000:02:00.0: [04]: 0x00035400 7033 7033 253 190
ath10k_pci 0000:02:00.0: [05]: 0x00035800 0 0 64 0
ath10k_pci 0000:02:00.0: [06]: 0x00035c00 8 8 0 0
ath10k_pci 0000:02:00.0: [07]: 0x00036000 1 1 1 1
ieee80211 phy0: Hardware restart was requested
ath10k_pci 0000:02:00.0: firmware crashed! (guid
4f81011e-ff0e-42d1-8f97-74a576157bc7)
ath10k_pci 0000:02:00.0: qca9377 hw1.1 target 0x05020001 chip_id
0x003821ff sub 1a3b:2b31
ath10k_pci 0000:02:00.0: kconfig debug 0 debugfs 1 tracing 1 dfs 0 testmode 0
ath10k_pci 0000:02:00.0: firmware ver WLAN.TF.1.0-00002-QCATFSWPZ-5
api 5 features ignore-otp crc32 c3e0d04f
ath10k_pci 0000:02:00.0: board_file api 2 bmi_id N/A crc32 8aedfa4a
ath10k_pci 0000:02:00.0: htt-ver 3.44 wmi-op 4 htt-op 3 cal otp
max-sta 32 raw 0 hwcrypto 1
ath10k_pci 0000:02:00.0: firmware register dump:
ath10k_pci 0000:02:00.0: [00]: 0x05020001 0x00000000 0x809FF705 0x00000000
ath10k_pci 0000:02:00.0: [04]: 0x809FF705 0x0040EA78 0x0043DA00 0x0042C514
ath10k_pci 0000:02:00.0: [08]: 0x004301B0 0x004301C0 0x00000064 0x00000000
ath10k_pci 0000:02:00.0: [12]: 0x809B140B 0x004301C0 0x004301C8 0x00000064
ath10k_pci 0000:02:00.0: [16]: 0x00000000 0x0040EABC 0x00000064 0x0040EAB0
ath10k_pci 0000:02:00.0: [20]: 0x000FFFFF 0x0040EAE8 0x00000011 0x004041E4
ath10k_pci 0000:02:00.0: [24]: 0x00020000 0x00020000 0x00400000 0x00000001
ath10k_pci 0000:02:00.0: [28]: 0x809FCDD8 0x0040EA98 0x0043DA00 0x00000001
ath10k_pci 0000:02:00.0: [32]: 0x00000001 0x004122C0 0x00426BD0 0x00035428
ath10k_pci 0000:02:00.0: [36]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [40]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [44]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [48]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [52]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [56]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: Copy Engine register dump:
ath10k_pci 0000:02:00.0: [00]: 0x00034400 2 2 3 3
ath10k_pci 0000:02:00.0: [01]: 0x00034800 3 3 16 17
ath10k_pci 0000:02:00.0: [02]: 0x00034c00 1 1 0 1
ath10k_pci 0000:02:00.0: [03]: 0x00035000 1 1 2 1
ath10k_pci 0000:02:00.0: [04]: 0x00035400 14 14 64 6
ath10k_pci 0000:02:00.0: [05]: 0x00035800 0 0 0 0
ath10k_pci 0000:02:00.0: [06]: 0x00035c00 0 0 0 0
ath10k_pci 0000:02:00.0: [07]: 0x00036000 1 1 1 1
ath10k_pci 0000:02:00.0: wmi unified ready event not received
ath10k_pci 0000:02:00.0: device has crashed during init
ath10k_pci 0000:02:00.0: device has crashed during init
ath10k_pci 0000:02:00.0: failed to wait for target init: -70
ath10k_pci 0000:02:00.0: Could not init core: -110
------------[ cut here ]------------
Hardware became unavailable during restart.
ath10k_pci 0000:02:00.0: cannot restart a device that hasn't been started
WARNING: CPU: 2 PID: 316 at
/usr/src/packages/BUILD/net/mac80211/util.c:1907
ieee80211_reconfig+0x235/0xf70 [mac80211]
Modules linked in: uas usb_storage ccm rfcomm arc4 joydev cmac bnep
hid_multitouch hid_generic spi_pxa2xx_platform 8250_dw intel_rapl
intel_telemetry_pltdrv intel_punit_ipc intel_telemetry_core
intel_pmc_ipc x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel
snd_soc_skl kvm irqbypass crct10dif_pclmul snd_soc_skl_ipc
snd_soc_sst_ipc snd_soc_sst_dsp crc32_pclmul snd_hda_ext_core
snd_hda_codec_hdmi ghash_clmulni_intel snd_soc_acpi pcbc snd_soc_core
snd_hda_codec_realtek snd_hda_codec_generic snd_compress uvcvideo
videobuf2_vmalloc ac97_bus aesni_intel videobuf2_memops videobuf2_v4l2
aes_x86_64 snd_pcm_dmaengine crypto_simd videobuf2_common cryptd
glue_helper videodev snd_hda_intel ath10k_pci intel_cstate
snd_hda_codec intel_rapl_perf media ath10k_core snd_hda_core snd_hwdep
btusb btrtl
btbcm btintel ath snd_pcm asus_nb_wmi asus_wmi mac80211 snd_timer
sparse_keymap bluetooth input_leds wmi_bmof bfq snd soundcore
ecdh_generic rtsx_pci_ms memstick cfg80211 idma64 virt_dma
intel_lpss_pci intel_lpss mei_me processor_thermal_device mei
intel_soc_dts_iosf mac_hid int3400_thermal int3403_thermal
acpi_thermal_rel int340x_thermal_zone pinctrl_geminilake asus_wireless
zram ip_tables x_tables mmc_block rtsx_pci_sdmmc i915 i2c_algo_bit
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops serio_raw
ahci sdhci_pci rtsx_pci drm cqhci sdhci libahci wmi i2c_hid hid video
CPU: 2 PID: 316 Comm: kworker/2:5 Not tainted 4.18.0-15-generic
#16+dev706.ddb1008beos3.5.2
Hardware name: ASUSTeK COMPUTER INC. VivoBook_ASUS Laptop
E406MA_E406MA/E406MA, BIOS E406MA.311 03/14/2019
Workqueue: events_freezable ieee80211_restart_work [mac80211]
RIP: 0010:ieee80211_reconfig+0x235/0xf70 [mac80211]
Code: c6 45 d6 00 c6 83 94 04 00 00 00 48 89 df e8 f2 a9 fc ff 85 c0
41 89 c6 0f 84 40 01 00 00 48 c7 c7 b8 b1 a6 c0 e8 fb b4 c6 dc <0f> 0b
e9 48 fe ff ff 4c 89 e7 e8 dc 09 02 00 e9 13 ff ff ff c6 83
RSP: 0018:ffffad7c80a57de8 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff8870af2b0760 RCX: 0000000000000006
RDX: 0000000000000007 RSI: 0000000000000082 RDI: ffff8870bfd16540
RBP: ffffad7c80a57e30 R08: 0000000000000001 R09: 00000000000003a9
R10: 00000000000000c9 R11: 00000000000003a9 R12: ffff8870af2b0f90
R13: ffff8870af2b13a0 R14: 00000000ffffff92 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8870bfd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00003eb20551d000 CR3: 0000000150908000 CR4: 0000000000340ee0
Call Trace:
ieee80211_restart_work+0xbc/0xf0 [mac80211]
process_one_work+0x1fa/0x3f0
worker_thread+0x4d/0x410
kthread+0x105/0x140
? rescuer_thread+0x370/0x370
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x1f/0x40
---[ end trace bfb7f12d31b47270 ]---
followed by many more similar warnings.
This problem can be easily reproduced by playing youtube videos for a
few minutes. When it happens, the system does not recover and the wifi
is unusable til reboot.
We have confirmed that this problem only affects specific cards. Other
identical-looking QCA9377 cards found in other instances of the same
laptop products do not suffer the problem. If we move an affected card
to another laptop, the problem will then readily occur on that laptop
too, i.e. the problem follows the card.
Having seen multiple cards that follow this pattern, it does not
appear to be a one-off.
It also does not appear to be an actual defect with the hardware
because we've tested the same cards extensively under Windows 10 and
no problems are seen there.
Any suggestions for further debugging?
We would be happy to ship affected devices to Qualcomm engineers if that helps.
Thanks
Daniel
^ permalink raw reply
* Re: [PATCH] rsi: Properly initialize data in rsi_sdio_ta_reset
From: Nathan Chancellor @ 2019-05-23 1:54 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Amitkumar Karwar, Siva Rebbagondla, Kalle Valo, linux-wireless,
netdev, LKML, clang-built-linux
In-Reply-To: <20190503031718.GB6969@archlinux-i9>
On Thu, May 02, 2019 at 08:17:18PM -0700, Nathan Chancellor wrote:
> On Thu, May 02, 2019 at 11:18:01AM -0700, Nick Desaulniers wrote:
> > On Thu, May 2, 2019 at 8:16 AM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > >
> > > When building with -Wuninitialized, Clang warns:
> > >
> > > drivers/net/wireless/rsi/rsi_91x_sdio.c:940:43: warning: variable 'data'
> > > is uninitialized when used here [-Wuninitialized]
> > > put_unaligned_le32(TA_HOLD_THREAD_VALUE, data);
> > > ^~~~
> > > drivers/net/wireless/rsi/rsi_91x_sdio.c:930:10: note: initialize the
> > > variable 'data' to silence this warning
> > > u8 *data;
> > > ^
> > > = NULL
> > > 1 warning generated.
> > >
> > > Using Clang's suggestion of initializing data to NULL wouldn't work out
> > > because data will be dereferenced by put_unaligned_le32. Use kzalloc to
> > > properly initialize data, which matches a couple of other places in this
> > > driver.
> > >
> > > Fixes: e5a1ecc97e5f ("rsi: add firmware loading for 9116 device")
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/464
> > > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > > ---
> > > drivers/net/wireless/rsi/rsi_91x_sdio.c | 21 ++++++++++++++-------
> > > 1 file changed, 14 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c
> > > index f9c67ed473d1..b35728564c7b 100644
> > > --- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
> > > +++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
> > > @@ -929,11 +929,15 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
> > > u32 addr;
> > > u8 *data;
> > >
> > > + data = kzalloc(sizeof(u32), GFP_KERNEL);
> >
> > Something fishy is going on here. We allocate 4 B but declare data as
> > a u8* (pointer to individual bytes)? In general, dynamically
> > allocating that few bytes is a code smell; either you meant to just
> > use the stack, or this memory's lifetime extends past the lifetime of
> > this stackframe, at which point you probably just meant to stack
> > allocate space in a higher parent frame and pass this preallocated
> > memory down to the child frame to get filled in.
> >
> > Reading through this code, I don't think that the memory is meant to
> > outlive the stack frame. Is there a reason why we can't just declare
> > data as:
> >
> > u8 data [4];
>
> data was __le32 in rsi_reset_chip() before commit f700546682a6 ("rsi:
> fix nommu_map_sg overflow kernel panic").
>
> I wonder if this would be okay for this function:
>
> -------------------------------------------------
>
> diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c
> index f9c67ed473d1..0330c50ab99c 100644
> --- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
> +++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
> @@ -927,7 +927,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
> {
> int status;
> u32 addr;
> - u8 *data;
> + u8 data;
>
> status = rsi_sdio_master_access_msword(adapter, TA_BASE_ADDR);
> if (status < 0) {
> @@ -937,7 +937,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
> }
>
> rsi_dbg(INIT_ZONE, "%s: Bring TA out of reset\n", __func__);
> - put_unaligned_le32(TA_HOLD_THREAD_VALUE, data);
> + put_unaligned_le32(TA_HOLD_THREAD_VALUE, &data);
> addr = TA_HOLD_THREAD_REG | RSI_SD_REQUEST_MASTER;
> status = rsi_sdio_write_register_multiple(adapter, addr,
> (u8 *)&data,
> @@ -947,7 +947,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
> return status;
> }
>
> - put_unaligned_le32(TA_SOFT_RST_CLR, data);
> + put_unaligned_le32(TA_SOFT_RST_CLR, &data);
> addr = TA_SOFT_RESET_REG | RSI_SD_REQUEST_MASTER;
> status = rsi_sdio_write_register_multiple(adapter, addr,
> (u8 *)&data,
> @@ -957,7 +957,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
> return status;
> }
>
> - put_unaligned_le32(TA_PC_ZERO, data);
> + put_unaligned_le32(TA_PC_ZERO, &data);
> addr = TA_TH0_PC_REG | RSI_SD_REQUEST_MASTER;
> status = rsi_sdio_write_register_multiple(adapter, addr,
> (u8 *)&data,
> @@ -967,7 +967,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter)
> return -EINVAL;
> }
>
> - put_unaligned_le32(TA_RELEASE_THREAD_VALUE, data);
> + put_unaligned_le32(TA_RELEASE_THREAD_VALUE, &data);
> addr = TA_RELEASE_THREAD_REG | RSI_SD_REQUEST_MASTER;
> status = rsi_sdio_write_register_multiple(adapter, addr,
> (u8 *)&data,
>
>
> >
> > then use ARRAY_SIZE(data) or RSI_9116_REG_SIZE in rsi_reset_chip(),
> > getting rid of the kzalloc/kfree?
> >
> > (Sorry, I hate when a simple fixup becomes a "hey let's rewrite all
> > this code" thus becoming "that guy.")
>
> If we aren't actually improving the code, then why bother? :)
>
> Thank you for the review!
> Nathan
>
> > --
> > Thanks,
> > ~Nick Desaulniers
Hi all,
Did any of the maintainers have any comments on what the correct
solution is here to resolve this warning? It is one of the few left
before we can turn on -Wuninitialized for the whole kernel.
Thanks,
Nathan
^ permalink raw reply
* [PATCH AUTOSEL 5.1 047/375] mt76: remove mt76_queue dependency from tx_queue_skb function pointer
From: Sasha Levin @ 2019-05-22 19:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lorenzo Bianconi, Felix Fietkau, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190522192115.22666-1-sashal@kernel.org>
From: Lorenzo Bianconi <lorenzo@kernel.org>
[ Upstream commit 89a37842b0c13c9e568bf12f4fcbe6507147e41d ]
Remove mt76_queue dependency from tx_queue_skb function pointer and
rely on mt76_tx_qid instead. This is a preliminary patch to introduce
mt76_sw_queue support
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/dma.c | 3 ++-
drivers/net/wireless/mediatek/mt76/mt76.h | 4 ++--
drivers/net/wireless/mediatek/mt76/mt7603/beacon.c | 6 +++---
drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c | 4 ++--
drivers/net/wireless/mediatek/mt76/tx.c | 10 +++++-----
drivers/net/wireless/mediatek/mt76/usb.c | 3 ++-
6 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c
index 76629b98c78d7..8c7ee8302fb87 100644
--- a/drivers/net/wireless/mediatek/mt76/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/dma.c
@@ -271,10 +271,11 @@ mt76_dma_tx_queue_skb_raw(struct mt76_dev *dev, enum mt76_txq_id qid,
return 0;
}
-int mt76_dma_tx_queue_skb(struct mt76_dev *dev, struct mt76_queue *q,
+int mt76_dma_tx_queue_skb(struct mt76_dev *dev, enum mt76_txq_id qid,
struct sk_buff *skb, struct mt76_wcid *wcid,
struct ieee80211_sta *sta)
{
+ struct mt76_queue *q = &dev->q_tx[qid];
struct mt76_queue_entry e;
struct mt76_txwi_cache *t;
struct mt76_queue_buf buf[32];
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index bcbfd3c4a44b6..eb882b2cbc0ec 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -156,7 +156,7 @@ struct mt76_queue_ops {
struct mt76_queue_buf *buf, int nbufs, u32 info,
struct sk_buff *skb, void *txwi);
- int (*tx_queue_skb)(struct mt76_dev *dev, struct mt76_queue *q,
+ int (*tx_queue_skb)(struct mt76_dev *dev, enum mt76_txq_id qid,
struct sk_buff *skb, struct mt76_wcid *wcid,
struct ieee80211_sta *sta);
@@ -645,7 +645,7 @@ static inline struct mt76_tx_cb *mt76_tx_skb_cb(struct sk_buff *skb)
return ((void *) IEEE80211_SKB_CB(skb)->status.status_driver_data);
}
-int mt76_dma_tx_queue_skb(struct mt76_dev *dev, struct mt76_queue *q,
+int mt76_dma_tx_queue_skb(struct mt76_dev *dev, enum mt76_txq_id qid,
struct sk_buff *skb, struct mt76_wcid *wcid,
struct ieee80211_sta *sta);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/beacon.c b/drivers/net/wireless/mediatek/mt76/mt7603/beacon.c
index 4dcb465095d19..99c0a3ba37cb7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/beacon.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/beacon.c
@@ -23,7 +23,7 @@ mt7603_update_beacon_iter(void *priv, u8 *mac, struct ieee80211_vif *vif)
if (!skb)
return;
- mt76_dma_tx_queue_skb(&dev->mt76, &dev->mt76.q_tx[MT_TXQ_BEACON], skb,
+ mt76_dma_tx_queue_skb(&dev->mt76, MT_TXQ_BEACON, skb,
&mvif->sta.wcid, NULL);
spin_lock_bh(&dev->ps_lock);
@@ -118,8 +118,8 @@ void mt7603_pre_tbtt_tasklet(unsigned long arg)
struct ieee80211_vif *vif = info->control.vif;
struct mt7603_vif *mvif = (struct mt7603_vif *)vif->drv_priv;
- mt76_dma_tx_queue_skb(&dev->mt76, q, skb, &mvif->sta.wcid,
- NULL);
+ mt76_dma_tx_queue_skb(&dev->mt76, MT_TXQ_CAB, skb,
+ &mvif->sta.wcid, NULL);
}
mt76_queue_kick(dev, q);
spin_unlock_bh(&q->lock);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c b/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
index daaed1220147e..952fe19cba9b6 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c
@@ -146,8 +146,8 @@ static void mt76x02_pre_tbtt_tasklet(unsigned long arg)
struct ieee80211_vif *vif = info->control.vif;
struct mt76x02_vif *mvif = (struct mt76x02_vif *)vif->drv_priv;
- mt76_dma_tx_queue_skb(&dev->mt76, q, skb, &mvif->group_wcid,
- NULL);
+ mt76_dma_tx_queue_skb(&dev->mt76, MT_TXQ_PSD, skb,
+ &mvif->group_wcid, NULL);
}
spin_unlock_bh(&q->lock);
}
diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index 2585df5123350..0c1036da9a92a 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -286,7 +286,7 @@ mt76_tx(struct mt76_dev *dev, struct ieee80211_sta *sta,
q = &dev->q_tx[qid];
spin_lock_bh(&q->lock);
- dev->queue_ops->tx_queue_skb(dev, q, skb, wcid, sta);
+ dev->queue_ops->tx_queue_skb(dev, qid, skb, wcid, sta);
dev->queue_ops->kick(dev, q);
if (q->queued > q->ndesc - 8 && !q->stopped) {
@@ -327,7 +327,6 @@ mt76_queue_ps_skb(struct mt76_dev *dev, struct ieee80211_sta *sta,
{
struct mt76_wcid *wcid = (struct mt76_wcid *) sta->drv_priv;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
- struct mt76_queue *hwq = &dev->q_tx[MT_TXQ_PSD];
info->control.flags |= IEEE80211_TX_CTRL_PS_RESPONSE;
if (last)
@@ -335,7 +334,7 @@ mt76_queue_ps_skb(struct mt76_dev *dev, struct ieee80211_sta *sta,
IEEE80211_TX_CTL_REQ_TX_STATUS;
mt76_skb_set_moredata(skb, !last);
- dev->queue_ops->tx_queue_skb(dev, hwq, skb, wcid, sta);
+ dev->queue_ops->tx_queue_skb(dev, MT_TXQ_PSD, skb, wcid, sta);
}
void
@@ -390,6 +389,7 @@ mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_queue *hwq,
struct mt76_txq *mtxq, bool *empty)
{
struct ieee80211_txq *txq = mtxq_to_txq(mtxq);
+ enum mt76_txq_id qid = mt76_txq_get_qid(txq);
struct ieee80211_tx_info *info;
struct mt76_wcid *wcid = mtxq->wcid;
struct sk_buff *skb;
@@ -423,7 +423,7 @@ mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_queue *hwq,
if (ampdu)
mt76_check_agg_ssn(mtxq, skb);
- idx = dev->queue_ops->tx_queue_skb(dev, hwq, skb, wcid, txq->sta);
+ idx = dev->queue_ops->tx_queue_skb(dev, qid, skb, wcid, txq->sta);
if (idx < 0)
return idx;
@@ -458,7 +458,7 @@ mt76_txq_send_burst(struct mt76_dev *dev, struct mt76_queue *hwq,
if (cur_ampdu)
mt76_check_agg_ssn(mtxq, skb);
- idx = dev->queue_ops->tx_queue_skb(dev, hwq, skb, wcid,
+ idx = dev->queue_ops->tx_queue_skb(dev, qid, skb, wcid,
txq->sta);
if (idx < 0)
return idx;
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index 4c1abd4924054..b1551419338f0 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -726,10 +726,11 @@ mt76u_tx_build_sg(struct mt76_dev *dev, struct sk_buff *skb,
}
static int
-mt76u_tx_queue_skb(struct mt76_dev *dev, struct mt76_queue *q,
+mt76u_tx_queue_skb(struct mt76_dev *dev, enum mt76_txq_id qid,
struct sk_buff *skb, struct mt76_wcid *wcid,
struct ieee80211_sta *sta)
{
+ struct mt76_queue *q = &dev->q_tx[qid];
struct mt76u_buf *buf;
u16 idx = q->tail;
int err;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.1 060/375] iwlwifi: pcie: don't crash on invalid RX interrupt
From: Sasha Levin @ 2019-05-22 19:16 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johannes Berg, Luca Coelho, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190522192115.22666-1-sashal@kernel.org>
From: Johannes Berg <johannes.berg@intel.com>
[ Upstream commit 30f24eabab8cd801064c5c37589d803cb4341929 ]
If for some reason the device gives us an RX interrupt before we're
ready for it, perhaps during device power-on with misconfigured IRQ
causes mapping or so, we can crash trying to access the queues.
Prevent that by checking that we actually have RXQs and that they
were properly allocated.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
index 8d4f0628622bb..12f02aaf923ed 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1434,10 +1434,15 @@ static struct iwl_rx_mem_buffer *iwl_pcie_get_rxb(struct iwl_trans *trans,
static void iwl_pcie_rx_handle(struct iwl_trans *trans, int queue)
{
struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
- struct iwl_rxq *rxq = &trans_pcie->rxq[queue];
+ struct iwl_rxq *rxq;
u32 r, i, count = 0;
bool emergency = false;
+ if (WARN_ON_ONCE(!trans_pcie->rxq || !trans_pcie->rxq[queue].bd))
+ return;
+
+ rxq = &trans_pcie->rxq[queue];
+
restart:
spin_lock(&rxq->lock);
/* uCode's read index (stored in shared DRAM) indicates the last Rx
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.1 076/375] mac80211/cfg80211: update bss channel on channel switch
From: Sasha Levin @ 2019-05-22 19:16 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sergey Matyukevich, Johannes Berg, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190522192115.22666-1-sashal@kernel.org>
From: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
[ Upstream commit 5dc8cdce1d722c733f8c7af14c5fb595cfedbfa8 ]
FullMAC STAs have no way to update bss channel after CSA channel switch
completion. As a result, user-space tools may provide inconsistent
channel info. For instance, consider the following two commands:
$ sudo iw dev wlan0 link
$ sudo iw dev wlan0 info
The latter command gets channel info from the hardware, so most probably
its output will be correct. However the former command gets channel info
from scan cache, so its output will contain outdated channel info.
In fact, current bss channel info will not be updated until the
next [re-]connect.
Note that mac80211 STAs have a workaround for this, but it requires
access to internal cfg80211 data, see ieee80211_chswitch_work:
/* XXX: shouldn't really modify cfg80211-owned data! */
ifmgd->associated->channel = sdata->csa_chandef.chan;
This patch suggests to convert mac80211 workaround into cfg80211 behavior
and to update current bss channel in cfg80211_ch_switch_notify.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/mlme.c | 3 ---
net/wireless/nl80211.c | 5 +++++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 2dbcf5d5512ef..b7a9fe3d5fcb7 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1188,9 +1188,6 @@ static void ieee80211_chswitch_work(struct work_struct *work)
goto out;
}
- /* XXX: shouldn't really modify cfg80211-owned data! */
- ifmgd->associated->channel = sdata->csa_chandef.chan;
-
ifmgd->csa_waiting_bcn = true;
ieee80211_sta_reset_beacon_monitor(sdata);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 47e30a58566c2..d2a7459a5da43 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -15727,6 +15727,11 @@ void cfg80211_ch_switch_notify(struct net_device *dev,
wdev->chandef = *chandef;
wdev->preset_chandef = *chandef;
+
+ if (wdev->iftype == NL80211_IFTYPE_STATION &&
+ !WARN_ON(!wdev->current_bss))
+ wdev->current_bss->pub.channel = chandef->chan;
+
nl80211_ch_switch_notify(rdev, dev, chandef, GFP_KERNEL,
NL80211_CMD_CH_SWITCH_NOTIFY, 0);
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 035/317] brcm80211: potential NULL dereference in brcmf_cfg80211_vndr_cmds_dcmd_handler()
From: Sasha Levin @ 2019-05-22 19:18 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Kalle Valo, Sasha Levin, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev
In-Reply-To: <20190522192338.23715-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit e025da3d7aa4770bb1d1b3b0aa7cc4da1744852d ]
If "ret_len" is negative then it could lead to a NULL dereference.
The "ret_len" value comes from nl80211_vendor_cmd(), if it's negative
then we don't allocate the "dcmd_buf" buffer. Then we pass "ret_len" to
brcmf_fil_cmd_data_set() where it is cast to a very high u32 value.
Most of the functions in that call tree check whether the buffer we pass
is NULL but there are at least a couple places which don't such as
brcmf_dbg_hex_dump() and brcmf_msgbuf_query_dcmd(). We memcpy() to and
from the buffer so it would result in a NULL dereference.
The fix is to change the types so that "ret_len" can't be negative. (If
we memcpy() zero bytes to NULL, that's a no-op and doesn't cause an
issue).
Fixes: 1bacb0487d0e ("brcmfmac: replace cfg80211 testmode with vendor command")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
index 8eff2753abade..d493021f60318 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
@@ -35,9 +35,10 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct wiphy *wiphy,
struct brcmf_if *ifp;
const struct brcmf_vndr_dcmd_hdr *cmdhdr = data;
struct sk_buff *reply;
- int ret, payload, ret_len;
+ unsigned int payload, ret_len;
void *dcmd_buf = NULL, *wr_pointer;
u16 msglen, maxmsglen = PAGE_SIZE - 0x100;
+ int ret;
if (len < sizeof(*cmdhdr)) {
brcmf_err("vendor command too short: %d\n", len);
@@ -65,7 +66,7 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct wiphy *wiphy,
brcmf_err("oversize return buffer %d\n", ret_len);
ret_len = BRCMF_DCMD_MAXLEN;
}
- payload = max(ret_len, len) + 1;
+ payload = max_t(unsigned int, ret_len, len) + 1;
dcmd_buf = vzalloc(payload);
if (NULL == dcmd_buf)
return -ENOMEM;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 052/317] iwlwifi: pcie: don't crash on invalid RX interrupt
From: Sasha Levin @ 2019-05-22 19:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johannes Berg, Luca Coelho, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190522192338.23715-1-sashal@kernel.org>
From: Johannes Berg <johannes.berg@intel.com>
[ Upstream commit 30f24eabab8cd801064c5c37589d803cb4341929 ]
If for some reason the device gives us an RX interrupt before we're
ready for it, perhaps during device power-on with misconfigured IRQ
causes mapping or so, we can crash trying to access the queues.
Prevent that by checking that we actually have RXQs and that they
were properly allocated.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
index c596c7b13504d..4354c0fedda78 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1384,10 +1384,15 @@ static struct iwl_rx_mem_buffer *iwl_pcie_get_rxb(struct iwl_trans *trans,
static void iwl_pcie_rx_handle(struct iwl_trans *trans, int queue)
{
struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
- struct iwl_rxq *rxq = &trans_pcie->rxq[queue];
+ struct iwl_rxq *rxq;
u32 r, i, count = 0;
bool emergency = false;
+ if (WARN_ON_ONCE(!trans_pcie->rxq || !trans_pcie->rxq[queue].bd))
+ return;
+
+ rxq = &trans_pcie->rxq[queue];
+
restart:
spin_lock(&rxq->lock);
/* uCode's read index (stored in shared DRAM) indicates the last Rx
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 074/317] mwifiex: prevent an array overflow
From: Sasha Levin @ 2019-05-22 19:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190522192338.23715-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit b4c35c17227fe437ded17ce683a6927845f8c4a4 ]
The "rate_index" is only used as an index into the phist_data->rx_rate[]
array in the mwifiex_hist_data_set() function. That array has
MWIFIEX_MAX_AC_RX_RATES (74) elements and it's used to generate some
debugfs information. The "rate_index" variable comes from the network
skb->data[] and it is a u8 so it's in the 0-255 range. We need to cap
it to prevent an array overflow.
Fixes: cbf6e05527a7 ("mwifiex: add rx histogram statistics support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/marvell/mwifiex/cfp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c b/drivers/net/wireless/marvell/mwifiex/cfp.c
index bfe84e55df776..f1522fb1c1e87 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -531,5 +531,8 @@ u8 mwifiex_adjust_data_rate(struct mwifiex_private *priv,
rate_index = (rx_rate > MWIFIEX_RATE_INDEX_OFDM0) ?
rx_rate - 1 : rx_rate;
+ if (rate_index >= MWIFIEX_MAX_AC_RX_RATES)
+ rate_index = MWIFIEX_MAX_AC_RX_RATES - 1;
+
return rate_index;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 075/317] rsi: Fix NULL pointer dereference in kmalloc
From: Sasha Levin @ 2019-05-22 19:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Aditya Pakki, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190522192338.23715-1-sashal@kernel.org>
From: Aditya Pakki <pakki001@umn.edu>
[ Upstream commit d5414c2355b20ea8201156d2e874265f1cb0d775 ]
kmalloc can fail in rsi_register_rates_channels but memcpy still attempts
to write to channels. The patch replaces these calls with kmemdup and
passes the error upstream.
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 30 ++++++++++++---------
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index e56fc83faf0ef..2f604e8bc991b 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -188,27 +188,27 @@ bool rsi_is_cipher_wep(struct rsi_common *common)
* @adapter: Pointer to the adapter structure.
* @band: Operating band to be set.
*
- * Return: None.
+ * Return: int - 0 on success, negative error on failure.
*/
-static void rsi_register_rates_channels(struct rsi_hw *adapter, int band)
+static int rsi_register_rates_channels(struct rsi_hw *adapter, int band)
{
struct ieee80211_supported_band *sbands = &adapter->sbands[band];
void *channels = NULL;
if (band == NL80211_BAND_2GHZ) {
- channels = kmalloc(sizeof(rsi_2ghz_channels), GFP_KERNEL);
- memcpy(channels,
- rsi_2ghz_channels,
- sizeof(rsi_2ghz_channels));
+ channels = kmemdup(rsi_2ghz_channels, sizeof(rsi_2ghz_channels),
+ GFP_KERNEL);
+ if (!channels)
+ return -ENOMEM;
sbands->band = NL80211_BAND_2GHZ;
sbands->n_channels = ARRAY_SIZE(rsi_2ghz_channels);
sbands->bitrates = rsi_rates;
sbands->n_bitrates = ARRAY_SIZE(rsi_rates);
} else {
- channels = kmalloc(sizeof(rsi_5ghz_channels), GFP_KERNEL);
- memcpy(channels,
- rsi_5ghz_channels,
- sizeof(rsi_5ghz_channels));
+ channels = kmemdup(rsi_5ghz_channels, sizeof(rsi_5ghz_channels),
+ GFP_KERNEL);
+ if (!channels)
+ return -ENOMEM;
sbands->band = NL80211_BAND_5GHZ;
sbands->n_channels = ARRAY_SIZE(rsi_5ghz_channels);
sbands->bitrates = &rsi_rates[4];
@@ -227,6 +227,7 @@ static void rsi_register_rates_channels(struct rsi_hw *adapter, int band)
sbands->ht_cap.mcs.rx_mask[0] = 0xff;
sbands->ht_cap.mcs.tx_params = IEEE80211_HT_MCS_TX_DEFINED;
/* sbands->ht_cap.mcs.rx_highest = 0x82; */
+ return 0;
}
/**
@@ -1985,11 +1986,16 @@ int rsi_mac80211_attach(struct rsi_common *common)
wiphy->available_antennas_rx = 1;
wiphy->available_antennas_tx = 1;
- rsi_register_rates_channels(adapter, NL80211_BAND_2GHZ);
+ status = rsi_register_rates_channels(adapter, NL80211_BAND_2GHZ);
+ if (status)
+ return status;
wiphy->bands[NL80211_BAND_2GHZ] =
&adapter->sbands[NL80211_BAND_2GHZ];
if (common->num_supp_bands > 1) {
- rsi_register_rates_channels(adapter, NL80211_BAND_5GHZ);
+ status = rsi_register_rates_channels(adapter,
+ NL80211_BAND_5GHZ);
+ if (status)
+ return status;
wiphy->bands[NL80211_BAND_5GHZ] =
&adapter->sbands[NL80211_BAND_5GHZ];
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 076/317] net: cw1200: fix a NULL pointer dereference
From: Sasha Levin @ 2019-05-22 19:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kangjie Lu, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190522192338.23715-1-sashal@kernel.org>
From: Kangjie Lu <kjlu@umn.edu>
[ Upstream commit 0ed2a005347400500a39ea7c7318f1fea57fb3ca ]
In case create_singlethread_workqueue fails, the fix free the
hardware and returns NULL to avoid NULL pointer dereference.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/st/cw1200/main.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/st/cw1200/main.c b/drivers/net/wireless/st/cw1200/main.c
index 90dc979f260b6..c1608f0bf6d01 100644
--- a/drivers/net/wireless/st/cw1200/main.c
+++ b/drivers/net/wireless/st/cw1200/main.c
@@ -345,6 +345,11 @@ static struct ieee80211_hw *cw1200_init_common(const u8 *macaddr,
mutex_init(&priv->wsm_cmd_mux);
mutex_init(&priv->conf_mutex);
priv->workqueue = create_singlethread_workqueue("cw1200_wq");
+ if (!priv->workqueue) {
+ ieee80211_free_hw(hw);
+ return NULL;
+ }
+
sema_init(&priv->scan.lock, 1);
INIT_WORK(&priv->scan.work, cw1200_scan_work);
INIT_DELAYED_WORK(&priv->scan.probe_work, cw1200_probe_work);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 077/317] at76c50x-usb: Don't register led_trigger if usb_register_driver failed
From: Sasha Levin @ 2019-05-22 19:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: YueHaibing, Hulk Robot, Kalle Valo, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190522192338.23715-1-sashal@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit 09ac2694b0475f96be895848687ebcbba97eeecf ]
Syzkaller report this:
[ 1213.468581] BUG: unable to handle kernel paging request at fffffbfff83bf338
[ 1213.469530] #PF error: [normal kernel read fault]
[ 1213.469530] PGD 237fe4067 P4D 237fe4067 PUD 237e60067 PMD 1c868b067 PTE 0
[ 1213.473514] Oops: 0000 [#1] SMP KASAN PTI
[ 1213.473514] CPU: 0 PID: 6321 Comm: syz-executor.0 Tainted: G C 5.1.0-rc3+ #8
[ 1213.473514] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 1213.473514] RIP: 0010:strcmp+0x31/0xa0
[ 1213.473514] Code: 00 00 00 00 fc ff df 55 53 48 83 ec 08 eb 0a 84 db 48 89 ef 74 5a 4c 89 e6 48 89 f8 48 89 fa 48 8d 6f 01 48 c1 e8 03 83 e2 07 <42> 0f b6 04 28 38 d0 7f 04 84 c0 75 50 48 89 f0 48 89 f2 0f b6 5d
[ 1213.473514] RSP: 0018:ffff8881f2b7f950 EFLAGS: 00010246
[ 1213.473514] RAX: 1ffffffff83bf338 RBX: ffff8881ea6f7240 RCX: ffffffff825350c6
[ 1213.473514] RDX: 0000000000000000 RSI: ffffffffc1ee19c0 RDI: ffffffffc1df99c0
[ 1213.473514] RBP: ffffffffc1df99c1 R08: 0000000000000001 R09: 0000000000000004
[ 1213.473514] R10: 0000000000000000 R11: ffff8881de353f00 R12: ffff8881ee727900
[ 1213.473514] R13: dffffc0000000000 R14: 0000000000000001 R15: ffffffffc1eeaaf0
[ 1213.473514] FS: 00007fa66fa01700(0000) GS:ffff8881f7200000(0000) knlGS:0000000000000000
[ 1213.473514] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1213.473514] CR2: fffffbfff83bf338 CR3: 00000001ebb9e005 CR4: 00000000007606f0
[ 1213.473514] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1213.473514] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1213.473514] PKRU: 55555554
[ 1213.473514] Call Trace:
[ 1213.473514] led_trigger_register+0x112/0x3f0
[ 1213.473514] led_trigger_register_simple+0x7a/0x110
[ 1213.473514] ? 0xffffffffc1c10000
[ 1213.473514] at76_mod_init+0x77/0x1000 [at76c50x_usb]
[ 1213.473514] do_one_initcall+0xbc/0x47d
[ 1213.473514] ? perf_trace_initcall_level+0x3a0/0x3a0
[ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40
[ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40
[ 1213.473514] do_init_module+0x1b5/0x547
[ 1213.473514] load_module+0x6405/0x8c10
[ 1213.473514] ? module_frob_arch_sections+0x20/0x20
[ 1213.473514] ? kernel_read_file+0x1e6/0x5d0
[ 1213.473514] ? find_held_lock+0x32/0x1c0
[ 1213.473514] ? cap_capable+0x1ae/0x210
[ 1213.473514] ? __do_sys_finit_module+0x162/0x190
[ 1213.473514] __do_sys_finit_module+0x162/0x190
[ 1213.473514] ? __ia32_sys_init_module+0xa0/0xa0
[ 1213.473514] ? __mutex_unlock_slowpath+0xdc/0x690
[ 1213.473514] ? wait_for_completion+0x370/0x370
[ 1213.473514] ? vfs_write+0x204/0x4a0
[ 1213.473514] ? do_syscall_64+0x18/0x450
[ 1213.473514] do_syscall_64+0x9f/0x450
[ 1213.473514] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 1213.473514] RIP: 0033:0x462e99
[ 1213.473514] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
[ 1213.473514] RSP: 002b:00007fa66fa00c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 1213.473514] RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
[ 1213.473514] RDX: 0000000000000000 RSI: 0000000020000300 RDI: 0000000000000003
[ 1213.473514] RBP: 00007fa66fa00c70 R08: 0000000000000000 R09: 0000000000000000
[ 1213.473514] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa66fa016bc
[ 1213.473514] R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
If usb_register failed, no need to call led_trigger_register_simple.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 1264b951463a ("at76c50x-usb: add driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/atmel/at76c50x-usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/atmel/at76c50x-usb.c b/drivers/net/wireless/atmel/at76c50x-usb.c
index e99e766a30285..1cabae424839e 100644
--- a/drivers/net/wireless/atmel/at76c50x-usb.c
+++ b/drivers/net/wireless/atmel/at76c50x-usb.c
@@ -2585,8 +2585,8 @@ static int __init at76_mod_init(void)
if (result < 0)
printk(KERN_ERR DRIVER_NAME
": usb_register failed (status %d)\n", result);
-
- led_trigger_register_simple("at76_usb-tx", &ledtrig_tx);
+ else
+ led_trigger_register_simple("at76_usb-tx", &ledtrig_tx);
return result;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 081/317] ssb: Fix possible NULL pointer dereference in ssb_host_pcmcia_exit
From: Sasha Levin @ 2019-05-22 19:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: YueHaibing, Hulk Robot, Kalle Valo, Sasha Levin, linux-wireless,
netdev, bpf
In-Reply-To: <20190522192338.23715-1-sashal@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit b2c01aab9646ed8ffb7c549afe55d5349c482425 ]
Syzkaller report this:
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN PTI
CPU: 0 PID: 4492 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
RIP: 0010:sysfs_remove_file_ns+0x27/0x70 fs/sysfs/file.c:468
Code: 00 00 00 41 54 55 48 89 fd 53 49 89 d4 48 89 f3 e8 ee 76 9c ff 48 8d 7d 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 2d 48 89 da 48 b8 00 00 00 00 00 fc ff df 48 8b 6d
RSP: 0018:ffff8881e9d9fc00 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffffffff900367e0 RCX: ffffffff81a95952
RDX: 0000000000000006 RSI: ffffc90001405000 RDI: 0000000000000030
RBP: 0000000000000000 R08: fffffbfff1fa22ed R09: fffffbfff1fa22ed
R10: 0000000000000001 R11: fffffbfff1fa22ec R12: 0000000000000000
R13: ffffffffc1abdac0 R14: 1ffff1103d3b3f8b R15: 0000000000000000
FS: 00007fe409dc1700(0000) GS:ffff8881f1200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2d721000 CR3: 00000001e98b6005 CR4: 00000000007606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
sysfs_remove_file include/linux/sysfs.h:519 [inline]
driver_remove_file+0x40/0x50 drivers/base/driver.c:122
pcmcia_remove_newid_file drivers/pcmcia/ds.c:163 [inline]
pcmcia_unregister_driver+0x7d/0x2b0 drivers/pcmcia/ds.c:209
ssb_modexit+0xa/0x1b [ssb]
__do_sys_delete_module kernel/module.c:1018 [inline]
__se_sys_delete_module kernel/module.c:961 [inline]
__x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe409dc0c58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200000c0
RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe409dc16bc
R13: 00000000004bccaa R14: 00000000006f6bc8 R15: 00000000ffffffff
Modules linked in: ssb(-) 3c59x nvme_core macvlan tap pata_hpt3x3 rt2x00pci null_blk tsc40 pm_notifier_error_inject notifier_error_inject mdio cdc_wdm nf_reject_ipv4 ath9k_common ath9k_hw ath pppox ppp_generic slhc ehci_platform wl12xx wlcore tps6507x_ts ioc4 nf_synproxy_core ide_gd_mod ax25 can_dev iwlwifi can_raw atm tm2_touchkey can_gw can sundance adp5588_keys rt2800mmio rt2800lib rt2x00mmio rt2x00lib eeprom_93cx6 pn533 lru_cache elants_i2c ip_set nfnetlink gameport tipc hampshire nhc_ipv6 nhc_hop nhc_udp nhc_fragment nhc_routing nhc_mobility nhc_dest 6lowpan silead brcmutil nfc mt76_usb mt76 mac80211 iptable_security iptable_raw iptable_mangle iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_gre sit hsr veth vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon vcan bridge stp llc ip6_gre ip6_tunnel tunnel6 tun joydev mousedev serio_raw ide_pci_generic piix floppy ide_core sch_fq_codel ip_tables x_tables ipv6
[last unloaded: 3c59x]
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace 3913cbf8011e1c05 ]---
In ssb_modinit, it does not fail SSB init when ssb_host_pcmcia_init failed,
however in ssb_modexit, ssb_host_pcmcia_exit calls pcmcia_unregister_driver
unconditionally, which may tigger a NULL pointer dereference issue as above.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 399500da18f7 ("ssb: pick PCMCIA host code support from b43 driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ssb/bridge_pcmcia_80211.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/ssb/bridge_pcmcia_80211.c b/drivers/ssb/bridge_pcmcia_80211.c
index f51f150307dfb..ffa379efff83c 100644
--- a/drivers/ssb/bridge_pcmcia_80211.c
+++ b/drivers/ssb/bridge_pcmcia_80211.c
@@ -113,16 +113,21 @@ static struct pcmcia_driver ssb_host_pcmcia_driver = {
.resume = ssb_host_pcmcia_resume,
};
+static int pcmcia_init_failed;
+
/*
* These are not module init/exit functions!
* The module_pcmcia_driver() helper cannot be used here.
*/
int ssb_host_pcmcia_init(void)
{
- return pcmcia_register_driver(&ssb_host_pcmcia_driver);
+ pcmcia_init_failed = pcmcia_register_driver(&ssb_host_pcmcia_driver);
+
+ return pcmcia_init_failed;
}
void ssb_host_pcmcia_exit(void)
{
- pcmcia_unregister_driver(&ssb_host_pcmcia_driver);
+ if (!pcmcia_init_failed)
+ pcmcia_unregister_driver(&ssb_host_pcmcia_driver);
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 027/244] brcm80211: potential NULL dereference in brcmf_cfg80211_vndr_cmds_dcmd_handler()
From: Sasha Levin @ 2019-05-22 19:22 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Kalle Valo, Sasha Levin, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev
In-Reply-To: <20190522192630.24917-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit e025da3d7aa4770bb1d1b3b0aa7cc4da1744852d ]
If "ret_len" is negative then it could lead to a NULL dereference.
The "ret_len" value comes from nl80211_vendor_cmd(), if it's negative
then we don't allocate the "dcmd_buf" buffer. Then we pass "ret_len" to
brcmf_fil_cmd_data_set() where it is cast to a very high u32 value.
Most of the functions in that call tree check whether the buffer we pass
is NULL but there are at least a couple places which don't such as
brcmf_dbg_hex_dump() and brcmf_msgbuf_query_dcmd(). We memcpy() to and
from the buffer so it would result in a NULL dereference.
The fix is to change the types so that "ret_len" can't be negative. (If
we memcpy() zero bytes to NULL, that's a no-op and doesn't cause an
issue).
Fixes: 1bacb0487d0e ("brcmfmac: replace cfg80211 testmode with vendor command")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
index 8eff2753abade..d493021f60318 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
@@ -35,9 +35,10 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct wiphy *wiphy,
struct brcmf_if *ifp;
const struct brcmf_vndr_dcmd_hdr *cmdhdr = data;
struct sk_buff *reply;
- int ret, payload, ret_len;
+ unsigned int payload, ret_len;
void *dcmd_buf = NULL, *wr_pointer;
u16 msglen, maxmsglen = PAGE_SIZE - 0x100;
+ int ret;
if (len < sizeof(*cmdhdr)) {
brcmf_err("vendor command too short: %d\n", len);
@@ -65,7 +66,7 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct wiphy *wiphy,
brcmf_err("oversize return buffer %d\n", ret_len);
ret_len = BRCMF_DCMD_MAXLEN;
}
- payload = max(ret_len, len) + 1;
+ payload = max_t(unsigned int, ret_len, len) + 1;
dcmd_buf = vzalloc(payload);
if (NULL == dcmd_buf)
return -ENOMEM;
--
2.20.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