* Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN
From: Andrey Ryabinin @ 2017-09-26 16:49 UTC (permalink / raw)
To: Arnd Bergmann, David Laight
Cc: Mauro Carvalho Chehab, Jiri Pirko, Arend van Spriel, Kalle Valo,
David S. Miller, Alexander Potapenko, Dmitry Vyukov,
Masahiro Yamada, Michal Marek, Andrew Morton, Kees Cook,
Geert Uytterhoeven, Greg Kroah-Hartman,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com,
brcm80211-dev-list@cypress.com, kasan-dev@googlegroups.com,
linux-kbuild@vger.kernel.org, Jakub Jelinek, Martin Liška,
stable@vger.kernel.org
In-Reply-To: <CAK8P3a37Ts5q7BvA2JWse87huyAp+=e18CUXEt8731RrBnB+Ow@mail.gmail.com>
On 09/26/2017 09:47 AM, Arnd Bergmann wrote:
> On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Sep 25, 2017 at 7:41 AM, David Laight <David.Laight@aculab.com> wrote:
>>> From: Arnd Bergmann
>>>> Sent: 22 September 2017 22:29
>>> ...
>>>> It seems that this is triggered in part by using strlcpy(), which the
>>>> compiler doesn't recognize as copying at most 'len' bytes, since strlcpy
>>>> is not part of the C standard.
>>>
>>> Neither is strncpy().
>>>
>>> It'll almost certainly be a marker in a header file somewhere,
>>> so it should be possibly to teach it about other functions.
>>
>> I'm currently travelling and haven't investigated in detail, but from
>> taking a closer look here, I found that the hardened 'strlcpy()'
>> in include/linux/string.h triggers it. There is also a hardened
>> (much shorted) 'strncpy()' that doesn't trigger it in the same file,
>> and having only the extern declaration of strncpy also doesn't.
>
> And a little more experimenting leads to this simple patch that fixes
> the problem:
>
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -254,7 +254,7 @@ __FORTIFY_INLINE size_t strlcpy(char *p, const
> char *q, size_t size)
> size_t q_size = __builtin_object_size(q, 0);
> if (p_size == (size_t)-1 && q_size == (size_t)-1)
> return __real_strlcpy(p, q, size);
> - ret = strlen(q);
> + ret = __builtin_strlen(q);
I think this is not correct. Fortified strlen called here on purpose. If sizeof q is known at compile time
and 'q' contains not-null fortified strlen() will panic.
> if (size) {
> size_t len = (ret >= size) ? size - 1 : ret;
> if (__builtin_constant_p(len) && len >= p_size)
>
> The problem is apparently that the fortified strlcpy calls the fortified strlen,
> which in turn calls strnlen and that ends up calling the extern '__real_strnlen'
> that gcc cannot reduce to a constant expression for a constant input.
Per my observation, it's the code like this:
if ()
fortify_panic(__func__);
somehow prevent gcc to merge several "struct i2c_board_info info;" into one stack slot.
With the hack bellow, stack usage reduced to ~1,6K:
---
include/linux/string.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/include/linux/string.h b/include/linux/string.h
index 54d21783e18d..9a96ff3ebf94 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -261,8 +261,6 @@ __FORTIFY_INLINE __kernel_size_t strlen(const char *p)
if (p_size == (size_t)-1)
return __builtin_strlen(p);
ret = strnlen(p, p_size);
- if (p_size <= ret)
- fortify_panic(__func__);
return ret;
}
@@ -271,8 +269,6 @@ __FORTIFY_INLINE __kernel_size_t strnlen(const char *p, __kernel_size_t maxlen)
{
size_t p_size = __builtin_object_size(p, 0);
__kernel_size_t ret = __real_strnlen(p, maxlen < p_size ? maxlen : p_size);
- if (p_size <= ret && maxlen != ret)
- fortify_panic(__func__);
return ret;
}
> Not sure if that change is the best fix, but it seems to address the problem in
> this driver and probably leads to better code in other places as well.
>
Probably it would be better to solve this on the strlcpy side, but I haven't found the way to do this right.
Alternative solutions:
- use memcpy() instead of strlcpy(). All source strings are smaller than I2C_NAME_SIZE, so we could
do something like this - memcpy(info.type, "si2168", sizeof("si2168"));
Also this should be faster.
- Move code under different "case:" in the switch(dev->model) to the separate function should help as well.
But it might be harder to backport into stables.
^ permalink raw reply related
* Re: [PATCH] p54: don't unregister leds when they are inited
From: Andrey Konovalov @ 2017-09-26 15:12 UTC (permalink / raw)
To: Johannes Berg
Cc: Christian Lamparter, Kalle Valo, linux-wireless, netdev, LKML,
Dmitry Vyukov, Kostya Serebryany
In-Reply-To: <1506438516.22427.21.camel@sipsolutions.net>
On Tue, Sep 26, 2017 at 5:08 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> Subject should say *not* initialized?
Yes, sent v2.
>
> johannes
^ permalink raw reply
* [PATCH v2] p54: don't unregister leds when they are not initialized
From: Andrey Konovalov @ 2017-09-26 15:11 UTC (permalink / raw)
To: Christian Lamparter, Kalle Valo, linux-wireless, netdev,
linux-kernel
Cc: Dmitry Vyukov, Kostya Serebryany, Andrey Konovalov
ieee80211_register_hw() in p54_register_common() may fail and leds won't
get initialized. Currently p54_unregister_common() doesn't check that and
always calls p54_unregister_leds(). The fix is to check priv->registered
flag before calling p54_unregister_leds().
Found by syzkaller.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 1 PID: 1404 Comm: kworker/1:1 Not tainted
4.14.0-rc1-42251-gebb2c2437d80-dirty #205
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:16
dump_stack+0x292/0x395 lib/dump_stack.c:52
register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
__lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385
lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
flush_work+0xf0/0x8c0 kernel/workqueue.c:2886
__cancel_work_timer+0x51d/0x870 kernel/workqueue.c:2961
cancel_delayed_work_sync+0x1f/0x30 kernel/workqueue.c:3081
p54_unregister_leds+0x6c/0xc0 drivers/net/wireless/intersil/p54/led.c:160
p54_unregister_common+0x3d/0xb0 drivers/net/wireless/intersil/p54/main.c:856
p54u_disconnect+0x86/0x120 drivers/net/wireless/intersil/p54/p54usb.c:1073
usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
__device_release_driver drivers/base/dd.c:861
device_release_driver_internal+0x4f4/0x5c0 drivers/base/dd.c:893
device_release_driver+0x1e/0x30 drivers/base/dd.c:918
bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
device_del+0x5c4/0xab0 drivers/base/core.c:1985
usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
hub_port_connect drivers/usb/core/hub.c:4754
hub_port_connect_change drivers/usb/core/hub.c:5009
port_event drivers/usb/core/hub.c:5115
hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
process_scheduled_works kernel/workqueue.c:2179
worker_thread+0xb2b/0x1850 kernel/workqueue.c:2255
kthread+0x3a1/0x470 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
changes in v2:
- fixed typo in patch subject
---
drivers/net/wireless/intersil/p54/main.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/intersil/p54/main.c b/drivers/net/wireless/intersil/p54/main.c
index d5a3bf91a03e..ab6d39e12069 100644
--- a/drivers/net/wireless/intersil/p54/main.c
+++ b/drivers/net/wireless/intersil/p54/main.c
@@ -852,12 +852,11 @@ void p54_unregister_common(struct ieee80211_hw *dev)
{
struct p54_common *priv = dev->priv;
-#ifdef CONFIG_P54_LEDS
- p54_unregister_leds(priv);
-#endif /* CONFIG_P54_LEDS */
-
if (priv->registered) {
priv->registered = false;
+#ifdef CONFIG_P54_LEDS
+ p54_unregister_leds(priv);
+#endif /* CONFIG_P54_LEDS */
ieee80211_unregister_hw(dev);
}
--
2.14.1.821.g8fa685d3b7-goog
^ permalink raw reply related
* Re: [PATCH] p54: don't unregister leds when they are inited
From: Johannes Berg @ 2017-09-26 15:08 UTC (permalink / raw)
To: Andrey Konovalov, Christian Lamparter, Kalle Valo, linux-wireless,
netdev, linux-kernel
Cc: Dmitry Vyukov, Kostya Serebryany
In-Reply-To: <384966f3a79915b4617d808c40e63072aa8b868d.1506438160.git.andreyknvl@google.com>
Subject should say *not* initialized?
johannes
^ permalink raw reply
* Re: [RESEND] Re: usb/net/p54: trying to register non-static key in p54_unregister_leds
From: Andrey Konovalov @ 2017-09-26 15:06 UTC (permalink / raw)
To: Christian Lamparter
Cc: Johannes Berg, Kalle Valo, linux-wireless, netdev, LKML,
Dmitry Vyukov, Kostya Serebryany, syzkaller, Stephen Boyd,
Tejun Heo, Yong Zhang
In-Reply-To: <2589427.Vd4nrgaY4N@debian64>
On Sat, Sep 23, 2017 at 9:37 PM, 'Christian Lamparter' via syzkaller
<syzkaller@googlegroups.com> wrote:
> This got rejected by gmail once. Let's see if it works now.
>
> On Thursday, September 21, 2017 8:22:45 PM CEST Andrey Konovalov wrote:
>> On Wed, Sep 20, 2017 at 9:55 PM, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>> > On Wed, 2017-09-20 at 21:27 +0200, Christian Lamparter wrote:
>> >
>> >> It seems this is caused as a result of:
>> >> -> lock_map_acquire(&work->lockdep_map);
>> >> lock_map_release(&work->lockdep_map);
>> >>
>> >> in flush_work() [0]
>> >
>> > Agree.
>> >
>> >> This was added by:
>> >>
>> >> commit 0976dfc1d0cd80a4e9dfaf87bd8744612bde475a
>> >> Author: Stephen Boyd <sboyd@codeaurora.org>
>> >> Date: Fri Apr 20 17:28:50 2012 -0700
>> >>
>> >> workqueue: Catch more locking problems with flush_work()
>> >
>> > Yes, but that doesn't matter.
>> >
>> >> Looking at the Stephen's patch, it's clear that it was made
>> >> with "static DECLARE_WORK(work, my_work)" in mind. However
>> >> p54's led_work is "per-device", hence it is stored in the
>> >> devices context p54_common, which is dynamically allocated.
>> >> So, maybe revert Stephen's patch?
>> >
>> > I disagree - as the lockdep warning says:
>> >
>> >> > INFO: trying to register non-static key.
>> >> > the code is fine but needs lockdep annotation.
>> >> > turning off the locking correctness validator.
>> >
>> > What it needs is to actually correctly go through initializing the work
>> > at least once.
>> >
>> > Without more information, I can't really say what's going on, but I
>> > assume that something is failing and p54_unregister_leds() is getting
>> > invoked without p54_init_leds() having been invoked, so essentially
>> > it's trying to flush a work that was never initialized?
>> >
>> > INIT_DELAYED_WORK() does, after all, initialize the lockdep map
>> > properly via __INIT_WORK().
>
> Ok, thanks. This does indeed explain it.
>
> But this also begs the question: Is this really working then?
> From what I can tell, if CONFIG_LOCKDEP is not set then there's no BUG
> no WARN, no other splat or any other odd system behaviour. Does
> [cancel | flush]_[delayed_]work[_sync] really "just work" by *accident*,
> as long the delayed_work | work_struct is zeroed out?
> And should it work in the future as well?
>
>> Since I'm able to reproduce this, please let me know if you need me to
>> collect some debug traces to help with the triage.
>
> Do you want to take a shot at making a patch too? At a quick glance, it
> should be enough to move the [#ifdef CONFIG_P54_LEDS ... #endif] block
> in p54_unregister_common() into the if (priv->registered) { block
> (preferably before the ieee80211_unregister_hw(dev).
Just mailed a patch.
>
> Regards,
> Christian
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH] p54: don't unregister leds when they are inited
From: Andrey Konovalov @ 2017-09-26 15:05 UTC (permalink / raw)
To: Christian Lamparter, Kalle Valo, linux-wireless, netdev,
linux-kernel
Cc: Dmitry Vyukov, Kostya Serebryany, Andrey Konovalov
ieee80211_register_hw() in p54_register_common() may fail and leds won't
get initialized. Currently p54_unregister_common() doesn't check that and
always calls p54_unregister_leds(). The fix is to check priv->registered
flag before calling p54_unregister_leds().
Found by syzkaller.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 1 PID: 1404 Comm: kworker/1:1 Not tainted
4.14.0-rc1-42251-gebb2c2437d80-dirty #205
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:16
dump_stack+0x292/0x395 lib/dump_stack.c:52
register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
__lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385
lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
flush_work+0xf0/0x8c0 kernel/workqueue.c:2886
__cancel_work_timer+0x51d/0x870 kernel/workqueue.c:2961
cancel_delayed_work_sync+0x1f/0x30 kernel/workqueue.c:3081
p54_unregister_leds+0x6c/0xc0 drivers/net/wireless/intersil/p54/led.c:160
p54_unregister_common+0x3d/0xb0 drivers/net/wireless/intersil/p54/main.c:856
p54u_disconnect+0x86/0x120 drivers/net/wireless/intersil/p54/p54usb.c:1073
usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
__device_release_driver drivers/base/dd.c:861
device_release_driver_internal+0x4f4/0x5c0 drivers/base/dd.c:893
device_release_driver+0x1e/0x30 drivers/base/dd.c:918
bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
device_del+0x5c4/0xab0 drivers/base/core.c:1985
usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
hub_port_connect drivers/usb/core/hub.c:4754
hub_port_connect_change drivers/usb/core/hub.c:5009
port_event drivers/usb/core/hub.c:5115
hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
process_scheduled_works kernel/workqueue.c:2179
worker_thread+0xb2b/0x1850 kernel/workqueue.c:2255
kthread+0x3a1/0x470 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
drivers/net/wireless/intersil/p54/main.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/intersil/p54/main.c b/drivers/net/wireless/intersil/p54/main.c
index d5a3bf91a03e..ab6d39e12069 100644
--- a/drivers/net/wireless/intersil/p54/main.c
+++ b/drivers/net/wireless/intersil/p54/main.c
@@ -852,12 +852,11 @@ void p54_unregister_common(struct ieee80211_hw *dev)
{
struct p54_common *priv = dev->priv;
-#ifdef CONFIG_P54_LEDS
- p54_unregister_leds(priv);
-#endif /* CONFIG_P54_LEDS */
-
if (priv->registered) {
priv->registered = false;
+#ifdef CONFIG_P54_LEDS
+ p54_unregister_leds(priv);
+#endif /* CONFIG_P54_LEDS */
ieee80211_unregister_hw(dev);
}
--
2.14.1.821.g8fa685d3b7-goog
^ permalink raw reply related
* Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
From: Kalle Valo @ 2017-09-26 14:14 UTC (permalink / raw)
To: Christoph Hellwig
Cc: AceLan Kao, QCA ath9k Development, linux-wireless, netdev,
Linux-Kernel@Vger. Kernel. Org, Daniel Drake
In-Reply-To: <20170926140413.GA19977@infradead.org>
Christoph Hellwig <hch@infradead.org> writes:
> On Tue, Sep 26, 2017 at 03:26:51PM +0800, AceLan Kao wrote:
>> Ath9k is an old driver for old chips, and they work fine with legacy INTx.
>> But some new platforms are using it, so I think we should list those
>> new platforms which blocks INTx in the driver.
>
> And unless they are broken and need a quirk they should work even better
> with MSI if the device advertises MSI support in the PCI capabilities.
Daniel Drake (CCed) already found problems with the MSI implementation:
https://lkml.kernel.org/r/20170925041153.26574-1-drake@endlessm.com
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
From: Christoph Hellwig @ 2017-09-26 14:04 UTC (permalink / raw)
To: AceLan Kao
Cc: Christoph Hellwig, QCA ath9k Development, Kalle Valo,
linux-wireless, netdev, Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <CAFv23Qm9kZLSqJ_BP1D7mWCxekq0nt3S8onT1ckH-AoHDBUDzw@mail.gmail.com>
On Tue, Sep 26, 2017 at 03:26:51PM +0800, AceLan Kao wrote:
> Ath9k is an old driver for old chips, and they work fine with legacy INTx.
> But some new platforms are using it, so I think we should list those
> new platforms which blocks INTx in the driver.
And unless they are broken and need a quirk they should work even better
with MSI if the device advertises MSI support in the PCI capabilities.
^ permalink raw reply
* [PATCH] mac80211: aead api to reduce redundancy
From: Xiang Gao @ 2017-09-26 13:19 UTC (permalink / raw)
To: davem, johannes, linux-kernel, linux-wireless, netdev; +Cc: qasdfgtyuiop
Currently, the aes_ccm.c and aes_gcm.c are almost line by line copy of
each other. This patch reduce code redundancy by moving the code in these
two files to crypto/aead_api.c to make it a higher level aead api. The
file aes_ccm.c and aes_gcm.c are removed and all the functions there are
now implemented in their headers using the newly added aead api.
Signed-off-by: Xiang Gao <qasdfgtyuiop@gmail.com>
---
net/mac80211/Makefile | 3 +-
net/mac80211/{aes_gcm.c => aead_api.c} | 49 +++++++-------
net/mac80211/aead_api.h | 26 ++++++++
net/mac80211/aes_ccm.c | 115 ---------------------------------
net/mac80211/aes_ccm.h | 42 ++++++++----
net/mac80211/aes_gcm.h | 38 ++++++++---
net/mac80211/wpa.c | 12 ++--
7 files changed, 118 insertions(+), 167 deletions(-)
rename net/mac80211/{aes_gcm.c => aead_api.c} (55%)
create mode 100644 net/mac80211/aead_api.h
delete mode 100644 net/mac80211/aes_ccm.c
diff --git a/net/mac80211/Makefile b/net/mac80211/Makefile
index 282912245938..80f25ff2f24b 100644
--- a/net/mac80211/Makefile
+++ b/net/mac80211/Makefile
@@ -6,6 +6,7 @@ mac80211-y := \
driver-ops.o \
sta_info.o \
wep.o \
+ aead_api.o \
wpa.o \
scan.o offchannel.o \
ht.o agg-tx.o agg-rx.o \
@@ -15,8 +16,6 @@ mac80211-y := \
rate.o \
michael.o \
tkip.o \
- aes_ccm.o \
- aes_gcm.o \
aes_cmac.o \
aes_gmac.o \
fils_aead.o \
diff --git a/net/mac80211/aes_gcm.c b/net/mac80211/aead_api.c
similarity index 55%
rename from net/mac80211/aes_gcm.c
rename to net/mac80211/aead_api.c
index 8a4397cc1b08..6ac53d0c6977 100644
--- a/net/mac80211/aes_gcm.c
+++ b/net/mac80211/aead_api.c
@@ -1,7 +1,4 @@
-/*
- * Copyright 2014-2015, Qualcomm Atheros, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
+/* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
@@ -9,43 +6,43 @@
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/err.h>
+#include <linux/scatterlist.h>
#include <crypto/aead.h>
-#include <net/mac80211.h>
-#include "key.h"
-#include "aes_gcm.h"
+#include "aead_api.h"
-int ieee80211_aes_gcm_encrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic)
+int aead_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, size_t aad_len,
+ u8 *data, size_t data_len, u8 *auth)
{
struct scatterlist sg[3];
struct aead_request *aead_req;
int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
u8 *__aad;
- aead_req = kzalloc(reqsize + GCM_AAD_LEN, GFP_ATOMIC);
+ aead_req = kzalloc(reqsize + aad_len, GFP_ATOMIC);
if (!aead_req)
return -ENOMEM;
__aad = (u8 *)aead_req + reqsize;
- memcpy(__aad, aad, GCM_AAD_LEN);
+ memcpy(__aad, aad, aad_len);
sg_init_table(sg, 3);
- sg_set_buf(&sg[0], &__aad[2], be16_to_cpup((__be16 *)__aad));
+ sg_set_buf(&sg[0], __aad, aad_len);
sg_set_buf(&sg[1], data, data_len);
- sg_set_buf(&sg[2], mic, IEEE80211_GCMP_MIC_LEN);
+ sg_set_buf(&sg[2], auth, tfm->authsize);
aead_request_set_tfm(aead_req, tfm);
- aead_request_set_crypt(aead_req, sg, sg, data_len, j_0);
+ aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
crypto_aead_encrypt(aead_req);
kzfree(aead_req);
+
return 0;
}
-int ieee80211_aes_gcm_decrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic)
+int aead_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, size_t aad_len,
+ u8 *data, size_t data_len, u8 *auth)
{
struct scatterlist sg[3];
struct aead_request *aead_req;
@@ -56,21 +53,20 @@ int ieee80211_aes_gcm_decrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad,
if (data_len == 0)
return -EINVAL;
- aead_req = kzalloc(reqsize + GCM_AAD_LEN, GFP_ATOMIC);
+ aead_req = kzalloc(reqsize + aad_len, GFP_ATOMIC);
if (!aead_req)
return -ENOMEM;
__aad = (u8 *)aead_req + reqsize;
- memcpy(__aad, aad, GCM_AAD_LEN);
+ memcpy(__aad, aad, aad_len);
sg_init_table(sg, 3);
sg_set_buf(&sg[0], &__aad[2], be16_to_cpup((__be16 *)__aad));
sg_set_buf(&sg[1], data, data_len);
- sg_set_buf(&sg[2], mic, IEEE80211_GCMP_MIC_LEN);
+ sg_set_buf(&sg[2], auth, tfm->authsize);
aead_request_set_tfm(aead_req, tfm);
- aead_request_set_crypt(aead_req, sg, sg,
- data_len + IEEE80211_GCMP_MIC_LEN, j_0);
+ aead_request_set_crypt(aead_req, sg, sg, data_len + tfm->authsize, b_0);
aead_request_set_ad(aead_req, sg[0].length);
err = crypto_aead_decrypt(aead_req);
@@ -79,20 +75,21 @@ int ieee80211_aes_gcm_decrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad,
return err;
}
-struct crypto_aead *ieee80211_aes_gcm_key_setup_encrypt(const u8 key[],
- size_t key_len)
+struct crypto_aead *
+aead_key_setup_encrypt(const char *alg, const u8 key[],
+ size_t key_len, size_t authsize)
{
struct crypto_aead *tfm;
int err;
- tfm = crypto_alloc_aead("gcm(aes)", 0, CRYPTO_ALG_ASYNC);
+ tfm = crypto_alloc_aead(alg, 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm))
return tfm;
err = crypto_aead_setkey(tfm, key, key_len);
if (err)
goto free_aead;
- err = crypto_aead_setauthsize(tfm, IEEE80211_GCMP_MIC_LEN);
+ err = crypto_aead_setauthsize(tfm, authsize);
if (err)
goto free_aead;
@@ -103,7 +100,7 @@ struct crypto_aead *ieee80211_aes_gcm_key_setup_encrypt(const u8 key[],
return ERR_PTR(err);
}
-void ieee80211_aes_gcm_key_free(struct crypto_aead *tfm)
+void aead_key_free(struct crypto_aead *tfm)
{
crypto_free_aead(tfm);
}
diff --git a/net/mac80211/aead_api.h b/net/mac80211/aead_api.h
new file mode 100644
index 000000000000..141a813d410c
--- /dev/null
+++ b/net/mac80211/aead_api.h
@@ -0,0 +1,26 @@
+/* This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _AEAD_API_H
+#define _AEAD_API_H
+
+#include <crypto/aead.h>
+#include <linux/crypto.h>
+
+struct crypto_aead *
+aead_key_setup_encrypt(const char *alg, const u8 key[],
+ size_t key_len, size_t authsize);
+
+int aead_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
+ size_t aad_len, u8 *data,
+ size_t data_len, u8 *auth);
+
+int aead_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
+ size_t aad_len, u8 *data,
+ size_t data_len, u8 *auth);
+
+void aead_key_free(struct crypto_aead *tfm);
+
+#endif /* _AEAD_API_H */
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
deleted file mode 100644
index a4e0d59a40dd..000000000000
--- a/net/mac80211/aes_ccm.c
+++ /dev/null
@@ -1,115 +0,0 @@
-/*
- * Copyright 2003-2004, Instant802 Networks, Inc.
- * Copyright 2005-2006, Devicescape Software, Inc.
- *
- * Rewrite: Copyright (C) 2013 Linaro Ltd <ard.biesheuvel@linaro.org>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/kernel.h>
-#include <linux/types.h>
-#include <linux/err.h>
-#include <crypto/aead.h>
-
-#include <net/mac80211.h>
-#include "key.h"
-#include "aes_ccm.h"
-
-int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
- size_t mic_len)
-{
- struct scatterlist sg[3];
- struct aead_request *aead_req;
- int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
- u8 *__aad;
-
- aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
- if (!aead_req)
- return -ENOMEM;
-
- __aad = (u8 *)aead_req + reqsize;
- memcpy(__aad, aad, CCM_AAD_LEN);
-
- sg_init_table(sg, 3);
- sg_set_buf(&sg[0], &__aad[2], be16_to_cpup((__be16 *)__aad));
- sg_set_buf(&sg[1], data, data_len);
- sg_set_buf(&sg[2], mic, mic_len);
-
- aead_request_set_tfm(aead_req, tfm);
- aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
- aead_request_set_ad(aead_req, sg[0].length);
-
- crypto_aead_encrypt(aead_req);
- kzfree(aead_req);
-
- return 0;
-}
-
-int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
- size_t mic_len)
-{
- struct scatterlist sg[3];
- struct aead_request *aead_req;
- int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
- u8 *__aad;
- int err;
-
- if (data_len == 0)
- return -EINVAL;
-
- aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
- if (!aead_req)
- return -ENOMEM;
-
- __aad = (u8 *)aead_req + reqsize;
- memcpy(__aad, aad, CCM_AAD_LEN);
-
- sg_init_table(sg, 3);
- sg_set_buf(&sg[0], &__aad[2], be16_to_cpup((__be16 *)__aad));
- sg_set_buf(&sg[1], data, data_len);
- sg_set_buf(&sg[2], mic, mic_len);
-
- aead_request_set_tfm(aead_req, tfm);
- aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
- aead_request_set_ad(aead_req, sg[0].length);
-
- err = crypto_aead_decrypt(aead_req);
- kzfree(aead_req);
-
- return err;
-}
-
-struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
- size_t key_len,
- size_t mic_len)
-{
- struct crypto_aead *tfm;
- int err;
-
- tfm = crypto_alloc_aead("ccm(aes)", 0, CRYPTO_ALG_ASYNC);
- if (IS_ERR(tfm))
- return tfm;
-
- err = crypto_aead_setkey(tfm, key, key_len);
- if (err)
- goto free_aead;
- err = crypto_aead_setauthsize(tfm, mic_len);
- if (err)
- goto free_aead;
-
- return tfm;
-
-free_aead:
- crypto_free_aead(tfm);
- return ERR_PTR(err);
-}
-
-void ieee80211_aes_key_free(struct crypto_aead *tfm)
-{
- crypto_free_aead(tfm);
-}
diff --git a/net/mac80211/aes_ccm.h b/net/mac80211/aes_ccm.h
index fcd3254c5cf0..e9b7ca0bde5b 100644
--- a/net/mac80211/aes_ccm.h
+++ b/net/mac80211/aes_ccm.h
@@ -10,19 +10,39 @@
#ifndef AES_CCM_H
#define AES_CCM_H
-#include <linux/crypto.h>
+#include "aead_api.h"
#define CCM_AAD_LEN 32
-struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
- size_t key_len,
- size_t mic_len);
-int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
- size_t mic_len);
-int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
- size_t mic_len);
-void ieee80211_aes_key_free(struct crypto_aead *tfm);
+static inline struct crypto_aead *
+ieee80211_aes_key_setup_encrypt(const u8 key[], size_t key_len, size_t mic_len)
+{
+ return aead_key_setup_encrypt("ccm(aes)", key, key_len, mic_len);
+}
+
+static inline int
+ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm,
+ u8 *b_0, u8 *aad, u8 *data,
+ size_t data_len, u8 *mic)
+{
+ return aead_encrypt(tfm, b_0, aad + 2,
+ be16_to_cpup((__be16 *)aad),
+ data, data_len, mic);
+}
+
+static inline int
+ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm,
+ u8 *b_0, u8 *aad, u8 *data,
+ size_t data_len, u8 *mic)
+{
+ return aead_decrypt(tfm, b_0, aad + 2,
+ be16_to_cpup((__be16 *)aad),
+ data, data_len, mic);
+}
+
+static inline void ieee80211_aes_key_free(struct crypto_aead *tfm)
+{
+ return aead_key_free(tfm);
+}
#endif /* AES_CCM_H */
diff --git a/net/mac80211/aes_gcm.h b/net/mac80211/aes_gcm.h
index 55aed5352494..d2b096033009 100644
--- a/net/mac80211/aes_gcm.h
+++ b/net/mac80211/aes_gcm.h
@@ -9,16 +9,38 @@
#ifndef AES_GCM_H
#define AES_GCM_H
-#include <linux/crypto.h>
+#include "aead_api.h"
#define GCM_AAD_LEN 32
-int ieee80211_aes_gcm_encrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic);
-int ieee80211_aes_gcm_decrypt(struct crypto_aead *tfm, u8 *j_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic);
-struct crypto_aead *ieee80211_aes_gcm_key_setup_encrypt(const u8 key[],
- size_t key_len);
-void ieee80211_aes_gcm_key_free(struct crypto_aead *tfm);
+static inline int ieee80211_aes_gcm_encrypt(struct crypto_aead *tfm,
+ u8 *j_0, u8 *aad, u8 *data,
+ size_t data_len, u8 *mic)
+{
+ return aead_encrypt(tfm, j_0, aad + 2,
+ be16_to_cpup((__be16 *)aad),
+ data, data_len, mic);
+}
+
+static inline int ieee80211_aes_gcm_decrypt(struct crypto_aead *tfm,
+ u8 *j_0, u8 *aad, u8 *data,
+ size_t data_len, u8 *mic)
+{
+ return aead_decrypt(tfm, j_0, aad + 2,
+ be16_to_cpup((__be16 *)aad),
+ data, data_len, mic);
+}
+
+static inline struct crypto_aead *
+ieee80211_aes_gcm_key_setup_encrypt(const u8 key[], size_t key_len)
+{
+ return aead_key_setup_encrypt("gcm(aes)", key,
+ key_len, IEEE80211_GCMP_MIC_LEN);
+}
+
+static inline void ieee80211_aes_gcm_key_free(struct crypto_aead *tfm)
+{
+ return aead_key_free(tfm);
+}
#endif /* AES_GCM_H */
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index 0d722ea98a1b..390501bf9e31 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -464,7 +464,8 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb,
pos += IEEE80211_CCMP_HDR_LEN;
ccmp_special_blocks(skb, pn, b_0, aad);
return ieee80211_aes_ccm_encrypt(key->u.ccmp.tfm, b_0, aad, pos, len,
- skb_put(skb, mic_len), mic_len);
+ skb_put(skb,
+ key->u.ccmp.tfm->authsize));
}
@@ -540,10 +541,11 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx,
ccmp_special_blocks(skb, pn, b_0, aad);
if (ieee80211_aes_ccm_decrypt(
- key->u.ccmp.tfm, b_0, aad,
- skb->data + hdrlen + IEEE80211_CCMP_HDR_LEN,
- data_len,
- skb->data + skb->len - mic_len, mic_len))
+ key->u.ccmp.tfm, b_0, aad,
+ skb->data + hdrlen + IEEE80211_CCMP_HDR_LEN,
+ data_len,
+ skb->data + skb->len - key->u.ccmp.tfm->authsize
+ ))
return RX_DROP_UNUSABLE;
}
--
2.14.1
^ permalink raw reply related
* Re: [1/7] brcmfmac: handle FWHALT mailbox indication
From: James Hughes @ 2017-09-26 12:05 UTC (permalink / raw)
To: Arend van Spriel; +Cc: Kalle Valo, linux-wireless
In-Reply-To: <1381b572-184e-9cea-c83e-2c4f5d196a93@broadcom.com>
On 26 September 2017 at 12:11, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 25-09-17 11:30, James Hughes wrote:
>>
>> On 25 September 2017 at 10:26, James Hughes
>> <james.hughes@raspberrypi.org> wrote:
>>>
>>> On 25 September 2017 at 09:18, Kalle Valo <kvalo@codeaurora.org> wrote:
>>>>
>>>> Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
>>>>
>>>>> The firmware uses a mailbox to communicate to the host what is going
>>>>> on. In the driver we validate the bit received. Various people seen
>>>>> the following message:
>>>>>
>>>>> brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x4001=
2
>>>>>
>>>>> Bit 4 is cause of this message, but this actually indicates the
>>>>> firmware
>>>>> has halted. Handle this bit by giving a more meaningful error message=
.
>>>>>
>>>>> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
>>>>> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.co=
m>
>>>>> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
>>>>> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>>>>
>>>>
>>>> Failed to compile:
>>>>
>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c: In function
>>>> =E2=80=98brcmf_p2p_escan=E2=80=99:
>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:695:23: error:
>>>> =E2=80=98BRCMF_SCANTYPE_ACTIVE=E2=80=99 undeclared (first use in this =
function)
>>>> sparams->scan_type =3D BRCMF_SCANTYPE_ACTIVE;
>>>> ^
>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:695:23: note:
>>>> each undeclared identifier is reported only once for each function it
>>>> appears in
>>>> make[6]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.o]
>>>> Error 1
>>>> make[6]: *** Waiting for unfinished jobs....
>>>> make[5]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac] Error =
2
>>>> make[4]: *** [drivers/net/wireless/broadcom/brcm80211] Error 2
>>>> make[3]: *** [drivers/net/wireless/broadcom] Error 2
>>>> make[2]: *** [drivers/net/wireless] Error 2
>>>> make[1]: *** [drivers/net] Error 2
>>>> make: *** [drivers] Error 2
>>>>
>>>> 7 patches set to Changes Requested.
>>>>
>>>> 9948825 [1/7] brcmfmac: handle FWHALT mailbox indication
>>>> 9948831 [2/7] brcmfmac: disable packet filtering in promiscuous mode
>>>> 9948829 [3/7] brcmfmac: cleanup brcmf_cfg80211_escan() function
>>>> 9948833 [4/7] brcmfmac: use msecs_to_jiffies() instead of calculation
>>>> using HZ
>>>> 9948827 [5/7] brcmfmac: get rid of brcmf_cfg80211_escan() function
>>>> 9948823 [6/7] brcmfmac: get rid of struct
>>>> brcmf_cfg80211_info::active_scan field
>>>> 9948835 [7/7] brcmfmac: move configuration of probe request IEs
>>>>
>>>> --
>>>> https://patchwork.kernel.org/patch/9948825/
>>>>
>>>>
>>>> https://wireless.wiki.kernel.org/en/developers/documentation/submittin=
gpatches
>>>>
>>>
>>> We (Raspberry Pi) currently have an issue open with Cypress to try and
>>> determine the cause of the firmware lockup which results in this
>>> mailbox error, we have some custom firmware that has better firmware
>>> diagnostics which we have been reporting back to Cypress. Not had any
>>> progress so far as far as I know. Does this kernel side fix help our
>>> users in any way or is it simply a better error message?
>>>
>>> James
>>
>>
>> Sorry, should have read the patch first, simply a change to the error
>> reporting. I'll try and determine how far Cypress have got with the
>> firmware.
>
>
> Hi James,
>
> This was indeed only about getting rid of the "unknown mailbox" message. =
The
> times I have seen this also brcmf_sdio_checkdied() was printing a message
> that a firmware trap occurred. Does the forensics file in debugfs show
> anything for your issue or does the probe fail resulting in a detach.
>
> Regards,
> Arend
We have a lengthy thread on our github with as much information as I
know (https://github.com/raspberrypi/linux/issues/1342). Other Pi
users seem to have more luck replicating it that I do (no change
there), although I have a rig running now waiting for it to happen. We
are fairly sure that the firmware is locking up for some reason,
probably in a high usage, low reception environment, but I am not sure
if people can recover the wireless without reboot. We have test
firmware from Cypress with more diagnostics in the probable fault area
to help track it down, previous version have provided useful
forensics, but nothing on the latest firmware so far.
James
^ permalink raw reply
* [PATCH v2] mac80211: fix STA_SLOW_THRESHOLD htmldocs failure
From: Stanislaw Gruszka @ 2017-09-26 11:48 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, toke, Stanislaw Gruszka
Patch fixes htmldocs build problem:
Error(.//net/mac80211/sta_info.h:416): cannot understand prototype: 'STA_SLOW_THRESHOLD 6000 '
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
v1 -> v2: just fix documentation build, do not move the code.
net/mac80211/sta_info.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 3acbdfa..a35c964 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -398,7 +398,7 @@ struct ieee80211_sta_rx_stats {
u64 msdu[IEEE80211_NUM_TIDS + 1];
};
-/**
+/*
* The bandwidth threshold below which the per-station CoDel parameters will be
* scaled to be more lenient (to prevent starvation of slow stations). This
* value will be scaled by the number of active stations when it is being
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] mac80211: make STA_SLOW_THRESHOLD local
From: Stanislaw Gruszka @ 2017-09-26 11:23 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, toke
In-Reply-To: <1506421094.22427.8.camel@sipsolutions.net>
On Tue, Sep 26, 2017 at 12:18:14PM +0200, Johannes Berg wrote:
> On Tue, 2017-09-26 at 11:59 +0200, Stanislaw Gruszka wrote:
> > STA_SLOW_THRESHOLD is used only in one function, so don't need to be
> > global define.
> >
> > Patch also fixes problem of htmldocs build I encountered:
> >
> > Error(.//net/mac80211/sta_info.h:416): cannot understand prototype:
> > 'STA_SLOW_THRESHOLD 6000????'
>
> Why not just change /** to /*? I think it's better to keep it there
> even if it's not used, it's a more public thing than the code?
I thought local references are preferred over global. Fixing only
comment is fine for me, I'll post v2.
Stanislaw
^ permalink raw reply
* Re: [1/7] brcmfmac: handle FWHALT mailbox indication
From: Arend van Spriel @ 2017-09-26 11:11 UTC (permalink / raw)
To: James Hughes, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <CAE_XsMLpow8AT+uYq3WfN6tWw1TPcAbEMouguCgk6wU5fNi5hw@mail.gmail.com>
On 25-09-17 11:30, James Hughes wrote:
> On 25 September 2017 at 10:26, James Hughes
> <james.hughes@raspberrypi.org> wrote:
>> On 25 September 2017 at 09:18, Kalle Valo <kvalo@codeaurora.org> wrote:
>>> Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
>>>
>>>> The firmware uses a mailbox to communicate to the host what is going
>>>> on. In the driver we validate the bit received. Various people seen
>>>> the following message:
>>>>
>>>> brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
>>>>
>>>> Bit 4 is cause of this message, but this actually indicates the firmware
>>>> has halted. Handle this bit by giving a more meaningful error message.
>>>>
>>>> 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>
>>>
>>> Failed to compile:
>>>
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c: In function ‘brcmf_p2p_escan’:
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:695:23: error: ‘BRCMF_SCANTYPE_ACTIVE’ undeclared (first use in this function)
>>> sparams->scan_type = BRCMF_SCANTYPE_ACTIVE;
>>> ^
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:695:23: note: each undeclared identifier is reported only once for each function it appears in
>>> make[6]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.o] Error 1
>>> make[6]: *** Waiting for unfinished jobs....
>>> make[5]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac] Error 2
>>> make[4]: *** [drivers/net/wireless/broadcom/brcm80211] Error 2
>>> make[3]: *** [drivers/net/wireless/broadcom] Error 2
>>> make[2]: *** [drivers/net/wireless] Error 2
>>> make[1]: *** [drivers/net] Error 2
>>> make: *** [drivers] Error 2
>>>
>>> 7 patches set to Changes Requested.
>>>
>>> 9948825 [1/7] brcmfmac: handle FWHALT mailbox indication
>>> 9948831 [2/7] brcmfmac: disable packet filtering in promiscuous mode
>>> 9948829 [3/7] brcmfmac: cleanup brcmf_cfg80211_escan() function
>>> 9948833 [4/7] brcmfmac: use msecs_to_jiffies() instead of calculation using HZ
>>> 9948827 [5/7] brcmfmac: get rid of brcmf_cfg80211_escan() function
>>> 9948823 [6/7] brcmfmac: get rid of struct brcmf_cfg80211_info::active_scan field
>>> 9948835 [7/7] brcmfmac: move configuration of probe request IEs
>>>
>>> --
>>> https://patchwork.kernel.org/patch/9948825/
>>>
>>> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>>>
>>
>> We (Raspberry Pi) currently have an issue open with Cypress to try and
>> determine the cause of the firmware lockup which results in this
>> mailbox error, we have some custom firmware that has better firmware
>> diagnostics which we have been reporting back to Cypress. Not had any
>> progress so far as far as I know. Does this kernel side fix help our
>> users in any way or is it simply a better error message?
>>
>> James
>
> Sorry, should have read the patch first, simply a change to the error
> reporting. I'll try and determine how far Cypress have got with the
> firmware.
Hi James,
This was indeed only about getting rid of the "unknown mailbox" message.
The times I have seen this also brcmf_sdio_checkdied() was printing a
message that a firmware trap occurred. Does the forensics file in
debugfs show anything for your issue or does the probe fail resulting in
a detach.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] mac80211: make STA_SLOW_THRESHOLD local
From: Johannes Berg @ 2017-09-26 10:18 UTC (permalink / raw)
To: Stanislaw Gruszka, linux-wireless; +Cc: toke
In-Reply-To: <1506419987-22995-1-git-send-email-sgruszka@redhat.com>
On Tue, 2017-09-26 at 11:59 +0200, Stanislaw Gruszka wrote:
> STA_SLOW_THRESHOLD is used only in one function, so don't need to be
> global define.
>
> Patch also fixes problem of htmldocs build I encountered:
>
> Error(.//net/mac80211/sta_info.h:416): cannot understand prototype:
> 'STA_SLOW_THRESHOLD 6000 '
Why not just change /** to /*? I think it's better to keep it there
even if it's not used, it's a more public thing than the code?
johannes
^ permalink raw reply
* [PATCH] mac80211: make STA_SLOW_THRESHOLD local
From: Stanislaw Gruszka @ 2017-09-26 9:59 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, toke, Stanislaw Gruszka
STA_SLOW_THRESHOLD is used only in one function, so don't need to be
global define.
Patch also fixes problem of htmldocs build I encountered:
Error(.//net/mac80211/sta_info.h:416): cannot understand prototype: 'STA_SLOW_THRESHOLD 6000 '
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
net/mac80211/sta_info.c | 8 +++++++-
net/mac80211/sta_info.h | 8 --------
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 6961501..b79c2d0 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2319,10 +2319,16 @@ unsigned long ieee80211_sta_last_active(struct sta_info *sta)
static void sta_update_codel_params(struct sta_info *sta, u32 thr)
{
+ /* The bandwidth threshold below which the per-station CoDel parameters
+ * will be scaled to be more lenient (to prevent starvation of slow
+ * stations). Value will be scaled by the number of active stations.
+ */
+ const unsigned int slow_threshold = 6000; /* 6Mbps */
+
if (!sta->sdata->local->ops->wake_tx_queue)
return;
- if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {
+ if (thr && thr < slow_threshold * sta->local->num_sta) {
sta->cparams.target = MS2TIME(50);
sta->cparams.interval = MS2TIME(300);
sta->cparams.ecn = false;
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 3acbdfa..24eeab8 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -399,14 +399,6 @@ struct ieee80211_sta_rx_stats {
};
/**
- * The bandwidth threshold below which the per-station CoDel parameters will be
- * scaled to be more lenient (to prevent starvation of slow stations). This
- * value will be scaled by the number of active stations when it is being
- * applied.
- */
-#define STA_SLOW_THRESHOLD 6000 /* 6 Mbps */
-
-/**
* struct sta_info - STA information
*
* This structure collects information about a station that
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/3] rsi: sdio: add WOWLAN support for S3 suspend state
From: Kalle Valo @ 2017-09-26 9:59 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Amitkumar Karwar, Prameela Rani Garnepudi,
Karun Eagalapati
In-Reply-To: <1506345695-4654-1-git-send-email-amitkarwar@gmail.com>
Amitkumar Karwar <amitkarwar@gmail.com> writes:
> From: Karun Eagalapati <karun256@gmail.com>
>
> WoWLAN is supported in RS9113 device through GPIO pin2.
> wowlan config frame is internally sent to firmware in mac80211
> suspend handler. Also beacon miss threshold and keep-alive time
> values are increased to avoid un-necessary disconnection with AP.
>
> Signed-off-by: Karun Eagalapati <karun256@gmail.com>
> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com>
> ---
> drivers/net/wireless/rsi/Kconfig | 7 ++
> drivers/net/wireless/rsi/rsi_91x_core.c | 9 +-
> drivers/net/wireless/rsi/rsi_91x_mac80211.c | 125 ++++++++++++++++++++++++++++
> drivers/net/wireless/rsi/rsi_91x_mgmt.c | 66 +++++++++++++--
> drivers/net/wireless/rsi/rsi_91x_sdio.c | 11 +++
> drivers/net/wireless/rsi/rsi_common.h | 3 +
> drivers/net/wireless/rsi/rsi_main.h | 12 ++-
> drivers/net/wireless/rsi/rsi_mgmt.h | 37 +++++++-
> 8 files changed, 258 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/wireless/rsi/Kconfig b/drivers/net/wireless/rsi/Kconfig
> index 7c5e4ca..0882b4e 100644
> --- a/drivers/net/wireless/rsi/Kconfig
> +++ b/drivers/net/wireless/rsi/Kconfig
> @@ -42,4 +42,11 @@ config RSI_USB
> This option enables the USB bus support in rsi drivers.
> Select M (recommended), if you have a RSI 1x1 wireless module.
>
> +config RSI_WOW
> + bool "Redpine Signals WOWLAN support"
> + depends on RSI_SDIO && RSI_91X
> + default y
> + ---help---
> + Say Y, if you would like to enable wowlan support for RSI module.
This adds a lot of ifdefs to the code. Is the Kconfig option really
needed?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/3] rsi: sdio: Add WOWLAN support for S4 hibernate state
From: Kalle Valo @ 2017-09-26 9:57 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Amitkumar Karwar, Prameela Rani Garnepudi,
Karun Eagalapati
In-Reply-To: <1506345709-4699-1-git-send-email-amitkarwar@gmail.com>
Amitkumar Karwar <amitkarwar@gmail.com> writes:
> From: Karun Eagalapati <karun256@gmail.com>
>
> We are disabling of interrupts from firmware in freeze handler.
> Also setting power management capability KEEP_MMC_POWER to make
> device wakeup for WoWLAN trigger.
> At restore, we observed a device reset on some platforms. Hence
> reloading of firmware and device initialization is performed.
With "reloading of firmware and device initialization" you mean calling
rsi_mac80211_detach()?
void rsi_mac80211_detach(struct rsi_hw *adapter)
{
struct ieee80211_hw *hw = adapter->hw;
enum nl80211_band band;
if (hw) {
ieee80211_stop_queues(hw);
ieee80211_unregister_hw(hw);
ieee80211_free_hw(hw);
}
That looks like a quite heavy sledgehammer workaround to a resume
problem. Is it really the best way to handle this?
And even if that would be the right approach it needs to be properly
described in the commit log, a vague sentence in the end of a commit log
is not enough.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2] iwlwifi: mvm: allow monitor mode capture in STA mode
From: Coelho, Luciano @ 2017-09-26 7:59 UTC (permalink / raw)
To: linuxwifi, gavinli@thegavinli.com, Berg, Johannes,
Grumbach, Emmanuel
Cc: linux-wireless@vger.kernel.org, git@thegavinli.com
In-Reply-To: <20170915051148.2566-1-gavinli@thegavinli.com>
SGkgR2F2aW4sDQoNCk9uIFRodSwgMjAxNy0wOS0xNCBhdCAyMjoxMSAtMDcwMCwgZ2F2aW5saUB0
aGVnYXZpbmxpLmNvbSB3cm90ZToNCj4gRnJvbTogR2F2aW4gTGkgPGdpdEB0aGVnYXZpbmxpLmNv
bT4NCj4NCj4gT3BlbiB1cCB0aGUgZmlsdGVyIGlmIHRoZXJlIGlzIGEgbW9uaXRvciBpbnRlcmZh
Y2UgY29uZmlndXJlZDsgdGhpcw0KPiBhbGxvd3MgYWxsIHBhY2tldHMgb24gdGhlIGNoYW5uZWwg
dG8gYmUgY2FwdHVyZWQgZXZlbiBpZiB0aGUgZGV2aWNlIGlzDQo+IGluIFNUQSBtb2RlIGFuZCBh
c3NvY2lhdGVkIHRvIGEgQlNTLg0KPiANCj4gU2lnbmVkLW9mZi1ieTogR2F2aW4gTGkgPGdpdEB0
aGVnYXZpbmxpLmNvbT4NCj4gLS0tDQoNClNvcnJ5IGZvciB0aGUgZGVsYXkgaW4gcmVzcG9uZGlu
Zywgd2Ugd2VyZSBkaXNjdXNzaW5nIHRoaXMgcGF0Y2gNCmludGVybmFsbHkuDQoNClVuZm9ydHVu
YXRlbHkgdGhpcyBpcyBub3Qgc29tZXRoaW5nIHRoYXQgb3VyIGZpcm13YXJlIG9mZmljaWFsbHkN
CnN1cHBvcnRzLCBzbyB3ZSBjYW5ub3QgYWxsb3cgaXQgaW4gdGhlIGRyaXZlci4gIFRoZSBmaXJt
d2FyZSBkb2Vzbid0DQoqYmxvY2sqIHRoaXMgZnJvbSB3b3JraW5nLCBidXQgdGhlcmUgYXJlIG5v
IGd1YXJhbnRlZXMgdGhhdCBpdCB3aWxsIHdvcmsNCmFuZCB0aGF0IHRoZXJlIHdpbGwgbm90IGJl
IGFueSBzaWRlLWVmZmVjdHMuDQoNCklmIHRoaXMgd29ya3MgZm9yIHlvdSwgZmVlbCBmcmVlIHRv
IHVzZSBpdCAodGhhdCdzIG9uZSBvZiB0aGUgYmVhdXRpZXMNCm9mIG9wZW4gc291cmNlKSwgYnV0
IEkgd29uJ3QgYXBwbHkgaXQgaW4gdGhlIG1haW5saW5lIGRyaXZlci4NCg0KDQotLQ0KQ2hlZXJz
LA0KTHVjYS4=
^ permalink raw reply
* Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
From: AceLan Kao @ 2017-09-26 7:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: QCA ath9k Development, Kalle Valo, linux-wireless, netdev,
Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <20170926064456.GA28611@infradead.org>
Ath9k is an old driver for old chips, and they work fine with legacy INTx.
But some new platforms are using it, so I think we should list those
new platforms which blocks INTx in the driver.
BTW, new chips use ath10k driver.
2017-09-26 14:44 GMT+08:00 Christoph Hellwig <hch@infradead.org>:
> On Tue, Sep 26, 2017 at 02:41:35PM +0800, AceLan Kao wrote:
>> Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI
>> for WLAN device. So adding a quirk to list those machines and set
>> use_msi automatically.
>> Adding Dell Inspiron 24-3460 to the quirk.
>
> Huh? Using MSI should be the default, and skipping MSI should be
> a quirk if needed at all (usually it should be autodetected)
^ permalink raw reply
* Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN
From: Arnd Bergmann @ 2017-09-26 6:47 UTC (permalink / raw)
To: David Laight
Cc: Mauro Carvalho Chehab, Jiri Pirko, Arend van Spriel, Kalle Valo,
David S. Miller, Andrey Ryabinin, Alexander Potapenko,
Dmitry Vyukov, Masahiro Yamada, Michal Marek, Andrew Morton,
Kees Cook, Geert Uytterhoeven, Greg Kroah-Hartman,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com,
brcm80211-dev-list@cypress.com, kasan-dev@googlegroups.com,
linux-kbuild@vger.kernel.org, Jakub Jelinek, Martin Liška,
stable@vger.kernel.org
In-Reply-To: <CAK8P3a1zxjMsQTBPijCo8FJjEU5aRVTr7n_NZ1YM2UnDPKoRLw@mail.gmail.com>
On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Sep 25, 2017 at 7:41 AM, David Laight <David.Laight@aculab.com> wrote:
>> From: Arnd Bergmann
>>> Sent: 22 September 2017 22:29
>> ...
>>> It seems that this is triggered in part by using strlcpy(), which the
>>> compiler doesn't recognize as copying at most 'len' bytes, since strlcpy
>>> is not part of the C standard.
>>
>> Neither is strncpy().
>>
>> It'll almost certainly be a marker in a header file somewhere,
>> so it should be possibly to teach it about other functions.
>
> I'm currently travelling and haven't investigated in detail, but from
> taking a closer look here, I found that the hardened 'strlcpy()'
> in include/linux/string.h triggers it. There is also a hardened
> (much shorted) 'strncpy()' that doesn't trigger it in the same file,
> and having only the extern declaration of strncpy also doesn't.
And a little more experimenting leads to this simple patch that fixes
the problem:
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -254,7 +254,7 @@ __FORTIFY_INLINE size_t strlcpy(char *p, const
char *q, size_t size)
size_t q_size = __builtin_object_size(q, 0);
if (p_size == (size_t)-1 && q_size == (size_t)-1)
return __real_strlcpy(p, q, size);
- ret = strlen(q);
+ ret = __builtin_strlen(q);
if (size) {
size_t len = (ret >= size) ? size - 1 : ret;
if (__builtin_constant_p(len) && len >= p_size)
The problem is apparently that the fortified strlcpy calls the fortified strlen,
which in turn calls strnlen and that ends up calling the extern '__real_strnlen'
that gcc cannot reduce to a constant expression for a constant input.
Not sure if that change is the best fix, but it seems to address the problem in
this driver and probably leads to better code in other places as well.
Arnd
^ permalink raw reply
* Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
From: Christoph Hellwig @ 2017-09-26 6:44 UTC (permalink / raw)
To: AceLan Kao
Cc: QCA ath9k Development, Kalle Valo, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1506408099-18488-2-git-send-email-acelan.kao@canonical.com>
On Tue, Sep 26, 2017 at 02:41:35PM +0800, AceLan Kao wrote:
> Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI
> for WLAN device. So adding a quirk to list those machines and set
> use_msi automatically.
> Adding Dell Inspiron 24-3460 to the quirk.
Huh? Using MSI should be the default, and skipping MSI should be
a quirk if needed at all (usually it should be autodetected)
^ permalink raw reply
* [PATCH 6/6] ath9k: set use_msi=1 on Dell Inspiron 14-3473
From: AceLan Kao @ 2017-09-26 6:41 UTC (permalink / raw)
To: QCA ath9k Development, Kalle Valo, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1506408099-18488-1-git-send-email-acelan.kao@canonical.com>
BIOS on Dell Inspiron 14-3473 blocks legacy interrupts (INTx),
and only allows MSI for WLAN device.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
---
drivers/net/wireless/ath/ath9k/init.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index e1198e1..d03e1fc 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -136,6 +136,14 @@ static const struct dmi_system_id ath9k_quirks[] __initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 15-3572"),
},
},
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Inspiron 14-3473",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 14-3473"),
+ },
+ },
{}
};
--
2.7.4
^ permalink raw reply related
* [PATCH 5/6] ath9k: set use_msi=1 on Dell Vostro 15-3572
From: AceLan Kao @ 2017-09-26 6:41 UTC (permalink / raw)
To: QCA ath9k Development, Kalle Valo, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1506408099-18488-1-git-send-email-acelan.kao@canonical.com>
BIOS on Dell Vostro 15-3572 blocks legacy interrupts (INTx),
and only allows MSI for WLAN device.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
---
drivers/net/wireless/ath/ath9k/init.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index fce9ac7..e1198e1 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -128,6 +128,14 @@ static const struct dmi_system_id ath9k_quirks[] __initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 3472"),
},
},
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Vostro 15-3572",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 15-3572"),
+ },
+ },
{}
};
--
2.7.4
^ permalink raw reply related
* [PATCH 4/6] ath9k: set use_msi=1 on Dell Inspiron 3472
From: AceLan Kao @ 2017-09-26 6:41 UTC (permalink / raw)
To: QCA ath9k Development, Kalle Valo, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1506408099-18488-1-git-send-email-acelan.kao@canonical.com>
BIOS on Dell Inspiron 3472 blocks legacy interrupts (INTx),
and only allows MSI for WLAN device.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
---
drivers/net/wireless/ath/ath9k/init.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 6b5d53c..fce9ac7 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -120,6 +120,14 @@ static const struct dmi_system_id ath9k_quirks[] __initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 3262"),
},
},
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Inspiron 3472",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 3472"),
+ },
+ },
{}
};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/6] ath9k: set use_msi=1 on Dell Vostro 3262
From: AceLan Kao @ 2017-09-26 6:41 UTC (permalink / raw)
To: QCA ath9k Development, Kalle Valo, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1506408099-18488-1-git-send-email-acelan.kao@canonical.com>
BIOS on Dell Vostro 3262 blocks legacy interrupts (INTx),
and only allows MSI for WLAN device.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
---
drivers/net/wireless/ath/ath9k/init.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 1667949..6b5d53c 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -112,6 +112,14 @@ static const struct dmi_system_id ath9k_quirks[] __initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 24-3460"),
},
},
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Vostro 3262",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 3262"),
+ },
+ },
{}
};
--
2.7.4
^ 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