* [PATCH] Add SPDX identifiers
From: yegorslists @ 2019-06-20 13:01 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Yegor Yefremov
From: Yegor Yefremov <yegorslists@googlemail.com>
Software Package Data Exchange identifiers help to detect source file
licenses and hence simplify the FOSS compliance process.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
ap.c | 2 ++
bitrate.c | 2 ++
bloom.c | 2 ++
coalesce.c | 2 ++
connect.c | 2 ++
cqm.c | 2 ++
event.c | 2 ++
ftm.c | 2 ++
genl.c | 2 ++
hwsim.c | 2 ++
ibss.c | 2 ++
ieee80211.h | 2 ++
info.c | 2 ++
interface.c | 2 ++
iw.c | 2 ++
iw.h | 2 ++
link.c | 2 ++
measurements.c | 2 ++
mesh.c | 2 ++
mgmt.c | 2 ++
mpath.c | 2 ++
mpp.c | 2 ++
nan.c | 2 ++
nl80211.h | 2 ++
ocb.c | 2 ++
offch.c | 2 ++
p2p.c | 2 ++
phy.c | 2 ++
ps.c | 2 ++
reason.c | 2 ++
reg.c | 2 ++
roc.c | 2 ++
scan.c | 2 ++
sections.c | 2 ++
sha256.c | 2 ++
sha256.h | 2 ++
station.c | 2 ++
status.c | 2 ++
survey.c | 2 ++
util.c | 2 ++
vendor.c | 2 ++
wowlan.c | 2 ++
42 files changed, 84 insertions(+)
diff --git a/ap.c b/ap.c
index db9efb7..4b9157a 100644
--- a/ap.c
+++ b/ap.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
#include <netlink/genl/family.h>
diff --git a/bitrate.c b/bitrate.c
index 4a026a4..c0ff319 100644
--- a/bitrate.c
+++ b/bitrate.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include "nl80211.h"
diff --git a/bloom.c b/bloom.c
index 877a6b5..f697b94 100644
--- a/bloom.c
+++ b/bloom.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <inttypes.h>
#include "iw.h"
diff --git a/coalesce.c b/coalesce.c
index 36dcaef..f3826ca 100644
--- a/coalesce.c
+++ b/coalesce.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <stdio.h>
diff --git a/connect.c b/connect.c
index 3237a27..a486d21 100644
--- a/connect.c
+++ b/connect.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
diff --git a/cqm.c b/cqm.c
index 093b744..4e2e846 100644
--- a/cqm.c
+++ b/cqm.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
diff --git a/event.c b/event.c
index 100f644..a8b4611 100644
--- a/event.c
+++ b/event.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdint.h>
#include <stdbool.h>
#include <net/if.h>
diff --git a/ftm.c b/ftm.c
index 23be38e..03eaf38 100644
--- a/ftm.c
+++ b/ftm.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
diff --git a/genl.c b/genl.c
index 7dc27f7..f8dbac3 100644
--- a/genl.c
+++ b/genl.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
/*
* This ought to be provided by libnl
*/
diff --git a/hwsim.c b/hwsim.c
index 6f82207..fbfaed3 100644
--- a/hwsim.c
+++ b/hwsim.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/ibss.c b/ibss.c
index f6cbc4c..645639e 100644
--- a/ibss.c
+++ b/ibss.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <strings.h>
diff --git a/ieee80211.h b/ieee80211.h
index 8745608..0a7e205 100644
--- a/ieee80211.h
+++ b/ieee80211.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#ifndef __IEEE80211
#define __IEEE80211
diff --git a/info.c b/info.c
index e6270c8..fc0361d 100644
--- a/info.c
+++ b/info.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdbool.h>
#include <netlink/genl/genl.h>
diff --git a/interface.c b/interface.c
index b697482..de5546b 100644
--- a/interface.c
+++ b/interface.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <stdbool.h>
diff --git a/iw.c b/iw.c
index da71617..5bb22c4 100644
--- a/iw.c
+++ b/iw.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
/*
* nl80211 userspace tool
*
diff --git a/iw.h b/iw.h
index bc0b3ac..ea7bd6c 100644
--- a/iw.h
+++ b/iw.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#ifndef __IW_H
#define __IW_H
diff --git a/link.c b/link.c
index 1ed7f63..4e73279 100644
--- a/link.c
+++ b/link.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/measurements.c b/measurements.c
index 385143f..54ca402 100644
--- a/measurements.c
+++ b/measurements.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include "nl80211.h"
diff --git a/mesh.c b/mesh.c
index 0650d0c..2591a4b 100644
--- a/mesh.c
+++ b/mesh.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/mgmt.c b/mgmt.c
index 338435d..8639f9c 100644
--- a/mgmt.c
+++ b/mgmt.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <string.h>
#include <errno.h>
diff --git a/mpath.c b/mpath.c
index e39c24b..3cb465b 100644
--- a/mpath.c
+++ b/mpath.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/mpp.c b/mpp.c
index 58bf28e..23193a4 100644
--- a/mpp.c
+++ b/mpp.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
diff --git a/nan.c b/nan.c
index 1d8d795..a846b68 100644
--- a/nan.c
+++ b/nan.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/nl80211.h b/nl80211.h
index 6f09d15..750b116 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#ifndef __LINUX_NL80211_H
#define __LINUX_NL80211_H
/*
diff --git a/ocb.c b/ocb.c
index fc9579b..1678e49 100644
--- a/ocb.c
+++ b/ocb.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/offch.c b/offch.c
index 19e170e..684eea3 100644
--- a/offch.c
+++ b/offch.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
diff --git a/p2p.c b/p2p.c
index 2d4bab0..1d12046 100644
--- a/p2p.c
+++ b/p2p.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <netlink/genl/genl.h>
#include <netlink/genl/family.h>
#include <netlink/genl/ctrl.h>
diff --git a/phy.c b/phy.c
index 716677e..a5159c7 100644
--- a/phy.c
+++ b/phy.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdbool.h>
#include <errno.h>
#include <strings.h>
diff --git a/ps.c b/ps.c
index de36d2b..67f7a38 100644
--- a/ps.c
+++ b/ps.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/reason.c b/reason.c
index f91c681..74f516b 100644
--- a/reason.c
+++ b/reason.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdint.h>
#include "iw.h"
diff --git a/reg.c b/reg.c
index a2368df..7a83df2 100644
--- a/reg.c
+++ b/reg.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <stdbool.h>
diff --git a/roc.c b/roc.c
index c6eda10..a159487 100644
--- a/roc.c
+++ b/roc.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/scan.c b/scan.c
index 6ad3ad4..1993f0b 100644
--- a/scan.c
+++ b/scan.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/sections.c b/sections.c
index 38095f6..3b0ec8b 100644
--- a/sections.c
+++ b/sections.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include "iw.h"
SECTION(get);
diff --git a/sha256.c b/sha256.c
index 4a43df8..da9d967 100644
--- a/sha256.c
+++ b/sha256.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include "sha256.h"
/**
diff --git a/sha256.h b/sha256.h
index d3eb3c0..4a32604 100644
--- a/sha256.h
+++ b/sha256.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#ifndef SHA256
#define SHA256
diff --git a/station.c b/station.c
index aaad079..d8f0ae3 100644
--- a/station.c
+++ b/station.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/status.c b/status.c
index 731727d..7529021 100644
--- a/status.c
+++ b/status.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdint.h>
#include "iw.h"
diff --git a/survey.c b/survey.c
index 9325353..ffaf85a 100644
--- a/survey.c
+++ b/survey.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <netlink/genl/genl.h>
diff --git a/util.c b/util.c
index 41277b5..55993c7 100644
--- a/util.c
+++ b/util.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <ctype.h>
#include <netlink/attr.h>
#include <errno.h>
diff --git a/vendor.c b/vendor.c
index d203d85..7610354 100644
--- a/vendor.c
+++ b/vendor.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/wowlan.c b/wowlan.c
index 778c0db..71392d1 100644
--- a/wowlan.c
+++ b/wowlan.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <stdio.h>
--
2.17.0
^ permalink raw reply related
* Re: [PATCH 0/7] mmc: sdio: Various fixes/improvements for SDIO PM
From: Ulf Hansson @ 2019-06-20 13:43 UTC (permalink / raw)
To: linux-mmc@vger.kernel.org, Ulf Hansson, Adrian Hunter,
Douglas Anderson
Cc: Brian Norris, Shawn Lin, Guenter Roeck, Heiko Stuebner,
Kalle Valo, Arend Van Spriel, linux-wireless
In-Reply-To: <20190618153448.27145-1-ulf.hansson@linaro.org>
On Tue, 18 Jun 2019 at 17:34, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> The power management support implemented via system suspend/resume and runtime
> suspend/resume for SDIO cards is rather messy, but also fragile.
>
> This series makes some improvement to this code. In particular the so called
> powered-on re-initialization of SDIO card is quite questionable, I suspect
> it may never really worked well. Therefore this series removes this code, which
> helps to prepare for additional improvements on top in a later series.
>
> So far the series has only been compile tested, so any help in testing on HW for
> regressions is greatly appreciated.
>
> Kind regards
> Uffe
>
> Ulf Hansson (7):
> mmc: sdio: Turn sdio_run_irqs() into static
> mmc: sdio: Drop mmc_claim|release_host() in mmc_sdio_power_restore()
> mmc: sdio: Move comment about re-initialization to
> mmc_sdio_reinit_card()
> mmc: sdio: Drop powered-on re-init at runtime resume and HW reset
> mmc: sdio: Don't re-initialize powered-on removable SDIO cards at
> resume
> mmc: sdio: Drop unused in-parameter to mmc_sdio_reinit_card()
> mmc: sdio: Drop unused in-parameter from mmc_sdio_init_card()
>
> drivers/mmc/core/sdio.c | 92 +++++++++++++++----------------------
> drivers/mmc/core/sdio_irq.c | 3 +-
> include/linux/mmc/host.h | 1 -
> 3 files changed, 38 insertions(+), 58 deletions(-)
>
> --
> 2.17.1
>
I decided to queue this up, to see what tests from linux-next and
kernelCI reports.
Still, that doesn't mean I am appreciating test done on HW. I can also
apply tested-by tags by amending patches after this point.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH] carl9170: fix enum compare splat
From: Christian Lamparter @ 2019-06-20 14:41 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87a7ef9jp2.fsf@kamboji.qca.qualcomm.com>
On Tuesday, June 18, 2019 2:11:53 PM CEST Kalle Valo wrote:
> Christian Lamparter <chunkeey@gmail.com> writes:
> > On Monday, June 10, 2019 9:06:30 AM CEST Kalle Valo wrote:
> >> Christian Lamparter <chunkeey@gmail.com> writes:
> >>
> >> > This patch fixes a noisy warning triggered by -Wenum-compare
> >> >
> >> > |main.c:1390:31: warning: comparison between ‘enum nl80211_ac’
> >> > | and ‘enum ar9170_txq’ [-Wenum-compare]
> >> > | BUILD_BUG_ON(NL80211_NUM_ACS > __AR9170_NUM_TXQ);
> >> > | ^
> >> > | [...]
> >> >
> >> > This is a little bit unfortunate, since the number of queues
> >> > (hence NL80211_NUM_ACS) is a constant based on the IEEE 802.11
> >> > (much like IEEE80211_NUM_ACS) and __AR9170_NUM_TXQ is more or
> >> > less defined by the AR9170 hardware.
> >>
> >> Is the warning enabled by default? TBH I'm not seeing how useful this
> >> warning is for kernel development.
> >
> > It is included in the "-Wall" (which is coming from "KBUILD_CFLAGS"
> > in the main Makefile).
> >
> > I tried debian's gcc starting from 4.6 to the lastest 8.3. They all
> > complain about it in various degrees.
> >
> > https://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Warning-Options.html#Warning-Options
>
> Ok, odd that I haven't noticed this warning. Maybe I have been just
> blind.
Sorry. No, I messed up there. I made a patch back in the day during the spectre
mac80211 patches that I kept in my tree for the driver. But I now remember that
I never published those because of that exact "warning".
These lines are coming from there.
> >> > --- a/drivers/net/wireless/ath/carl9170/main.c
> >> > +++ b/drivers/net/wireless/ath/carl9170/main.c
> >> > @@ -1387,7 +1387,7 @@ static int carl9170_op_conf_tx(struct ieee80211_hw *hw,
> >> > int ret;
> >> >
> >> > BUILD_BUG_ON(ARRAY_SIZE(ar9170_qmap) != __AR9170_NUM_TXQ);
> >> > - BUILD_BUG_ON(NL80211_NUM_ACS > __AR9170_NUM_TXQ);
> >> > + BUILD_BUG_ON((size_t)NL80211_NUM_ACS > (size_t)__AR9170_NUM_TXQ);
> >>
> >> IMHO this just makes the code worse. Does it make sense to workaround
> >> (stupid) compiler warnings like this?
> >
> > True. What's worse: This isn't really code. The BUILD_BUG_ON Macro is there
> > to guard but it's getting compiled away. I could also just drop it.
>
> Either way is fine for me. If the GCC (by default) emits a warning for
> this we need to silence that warning, so in that respect I guess we
> should apply this. Unless better solutions come up, of course :)
Note: I dropped this patch from patchwork. So, there's nothing that
needs to be done now ;)
Well, except OT: Would you mind adding the QCA4019 boardfiles that
have accumulated over the past six-ish months?
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg09966.html>
That list already had:
ath10k-firmware: QCA4019 hw1.0: Add ASUS Lyra specific BDFs
ath10k-firmware: QCA4019 hw1.0: Add Linksys EA6350v3
ath10k-firmware: QCA4019 hw1.0: Add Qxwlan E2600AC specific BDFs
ath10k-firmware: QCA4019 hw1.0: Update OpenMesh A62 specific BDFs
ath10k-firmware: QCA9888 hw2.0: Update OpenMesh A62 specific BDFs
ath10k-firmware: QCA4019 hw1.0: Update OpenMesh A42 specific BDFs
ath10k-firmware: QCA4019 hw1.0: Add ALFA Network AP120C-AC specific BDF
ath10k-firmware: QCA4019 hw1.0: Add AVM FRITZ!Box 7530 specific BDFs
ath10k-firmware: QCA4019 hw1.0: Update Linksys EA6350v3 specific BDFs
and now there's even more:
+ ath10k-firmware: QCA4019 hw1.0: Add Qxwlan E2600AC specific BDFs
(Watch out, there are multiple versions! The first ones are dodgy
with a bad crc)
This should be the right "one"
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg10007.html>
+ ath10k-firmware: QCA4019 hw1.0: Add AVM FRITZ!Repeater 3000 specific BDFs
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg10101.html>
+ ath10k-firmware: IPQ4018 hw1.0: Add EnGenius ENS620EXT specific BDFs
<http://lists.infradead.org/pipermail/ath10k/2019-March/013034.html>
+ ath10k-firmware: QCA9984 hw1.0: Update Netgear Orbi Pro SRK60 specific BDFs
ath10k-firmware: QCA4019 hw1.0: Update Netgear Orbi Pro SRK60 specific BDFs
One for QCA9984 and one for two QCA4019
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg10170.html>
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg10171.html>
+ ath10k-firmware: IPQ4019 hw1.0: Add BDF for Linksys EA8300 [1/2]
ath10k-firmware: QCA9888 hw1.0: Add BDF for Linksys EA8300 [2/2]
<http://lists.infradead.org/pipermail/ath10k/2019-May/013403.html>
<http://lists.infradead.org/pipermail/ath10k/2019-May/013404.html>
Cheers,
Christian
^ permalink raw reply
* Re: [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
From: Denis Kenzior @ 2019-06-20 16:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <ec1ca95a5789f9001e89e603633b20316d687721.camel@sipsolutions.net>
Hi Johannes,
On 06/20/2019 01:58 AM, Johannes Berg wrote:
> Didn't really review all of this yet, but
>
> switch (state->split_start) {
>> case 0:
>> + if (nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN,
>> + rdev->wiphy.perm_addr))
>> + goto nla_put_failure;
>
> We generally can't add anything to any of the cases before the split was
> allowed, for compatibility with old userspace.
Can you educate me here? Is it because the non-split dump messages would
grow too large? But then non-dumps aren't split, so I still don't get
how anyone can be broken by this (that isn't already broken in the first
place).
Anyhow, What is the cut off point? It didn't seem worthwhile to send
yet-another-message for ~60 bytes of data, but if you want me to add it
as a separate message, no problem.
Regards,
-Denis
^ permalink raw reply
* Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk
From: Stefan Wahren @ 2019-06-20 18:01 UTC (permalink / raw)
To: Chi-Hsien Lin, Stanley Hsu, Arend van Spriel, Franky Lin,
Hante Meuleman, Wright Feng, linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com, brcm80211-dev-list,
Jouni Malinen
In-Reply-To: <605ea0a8-3303-b810-6223-18ccc7eb7af4@cypress.com>
Hi Chi-Hsien,
Am 17.06.19 um 10:04 schrieb Chi-Hsien Lin:
> (+Stanley)
>
> On 06/16/2019 1:21, Stefan Wahren wrote:
>> Am 15.06.19 um 19:01 schrieb Stefan Wahren:
>>> Hi,
>>>
>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>
>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
> Stefan,
>
> Could you please try the attached patch for your wpa_supplicant? We'll
> upstream if it works for you.
i tested your wpa_supplicant patch on top of current hostap-2.9-devel.
After applying the patch the driver warning disappeared.
Please take care of the upstream work.
Thanks
Stefan
>
> Regards,
> Chi-hsien Lin
^ permalink raw reply
* Re: [GIT PULL] MMC fixes for v5.2-rc6
From: pr-tracker-bot @ 2019-06-20 18:05 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linus, linux-mmc, linux-kernel, Ulf Hansson, Douglas Anderson,
Kalle Valo, Arend van Spriel, linux-wireless, Adrian Hunter
In-Reply-To: <20190620111602.17958-1-ulf.hansson@linaro.org>
The pull request you sent on Thu, 20 Jun 2019 13:16:02 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v5.2-rc4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6331d118ac61454ee52d5f9be098e9ddab6d6572
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk
From: Marcel Holtmann @ 2019-06-20 18:39 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Chi-Hsien Lin, Stefan Wahren, Stanley Hsu, Franky Lin,
Hante Meuleman, Wright Feng, linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com, brcm80211-dev-list,
Jouni Malinen
In-Reply-To: <a65a9b67-8307-12d0-9ef7-94bd2eb5badf@broadcom.com>
Hi Arend,
>>>>>>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>>>>>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>>>>>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>>>>>>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>>>>>>>
>>>>>>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>>>>>>
>>>>>>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>>>>>>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
>>>>>>
>>>>>> Stefan,
>>>>>>
>>>>>> Could you please try the attached patch for your wpa_supplicant? We'll
>>>>>> upstream if it works for you.
>>>>>
>>>>> I hope that someone is also providing a kernel patch to fix the issue. Hacking around a kernel issue in userspace is not enough. Fix the root cause in the kernel.
>>>> Marcel,
>>>> This is a kernel warning for invalid application PMK set actions, so the
>>>> fix is to only set PMK to wifi driver when 4-way is offloaded. I think
>>>> Arend added the WARN_ON() intentionally to catch application misuse of
>>>> PMK setting.
>>>> You may also remove the warnings with the attached patch, but let's see
>>>> what Arend says first.
>>>> Arend,
>>>> Any comment?
>>>
>>> Hi Chi-Hsien, Marcel
>>>
>>> From the kernel side I do not see an issue. In order to use 802.1X offload the NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in NL80211_CMD_CONNECT. Otherwise, NL80211_CMD_SET_PMK is not accepted. The only improvement would be to document this more clearly in the "WPA/WPA2 EAPOL handshake offload" DOC section in nl80211.h.
>> so nl80211 is an API. And an application can use that API wrongly (be that intentionally or unintentionally), the kernel can not just go WARN_ON and print a backtrace. That is your bug. So please handle wrong user input properly.
>
> You are right. However, the kernel does also return an error if the WARN_ON is hit. We can improve by using the EXT_ACK functionality to provide more info than just -EINVAL, eg. "PMK not accepted; no 802.1X offload requested on connect”.
just remove the WARN_ON and replace it with a dev_warn. Userspace should not be able to trigger WARN_ON by using nl80211.
>> Frankly, I don’t get why nl80211 itself is not validating the input and this is left to the driver. I think we need a nl80211 fuzzer that really exercises this API with random values and parameters to provide invalid input.
>
> That would mean nl80211 should keep state info between commands. From what I remember that has been avoided from day one because of the experiences with that in the WEXT days. I welcome any testing be it fuzzer or something else.
And now driver bugs are bleeding into the API. I expect from a kernel API that it hides driver details. From an userspace program perspective I expect exactly the same input validation and behavior no matter what hardware is used underneath. If we can not do that, then this API has a broken design.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
From: Johannes Berg @ 2019-06-20 19:17 UTC (permalink / raw)
To: Denis Kenzior; +Cc: linux-wireless
In-Reply-To: <7da9b924-78c7-ba72-fecc-a11700a34ff4@gmail.com>
Hi Denis,
> > We generally can't add anything to any of the cases before the split was
> > allowed, for compatibility with old userspace.
>
> Can you educate me here? Is it because the non-split dump messages would
> grow too large?
No. Those messages aren't really relevant, userspace will need to do a
larger buffer for it.
The problem is that old userspace (like really old) didn't split even
dumps. Eventually, we had so much information here that the default dump
message size is exceeded, and we simply couldn't dump that particular
wiphy anymore.
We solved this by splitting the wiphy information into multiple
messages, but that needed new userspace, so when userspace doesn't
request split dumps, we fall through all the way to "case 8" and then
stop - old userspace cannot care about new information anyway.
The reason it was split into cases 0-8 that are combined in non-split
dumps is that it was safer that way - there were certain configurations
where even the original data would go above the message size limit.
> Anyhow, What is the cut off point? It didn't seem worthwhile to send
> yet-another-message for ~60 bytes of data, but if you want me to add it
> as a separate message, no problem.
It doesn't matter if you add it as a separate message or not, you can
add it to later messages, i.e. anything in or after "case 9" is fine.
johannes
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in p54u_load_firmware_cb
From: Alan Stern @ 2019-06-20 19:46 UTC (permalink / raw)
To: syzbot
Cc: andreyknvl, chunkeey, davem, kvalo, Kernel development list,
USB list, linux-wireless, netdev, syzkaller-bugs
In-Reply-To: <000000000000f00cf1058bb7fb56@google.com>
On Wed, 19 Jun 2019, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit: 9939f56e usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=135e29faa00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=df134eda130bb43a
> dashboard link: https://syzkaller.appspot.com/bug?extid=6d237e74cdc13f036473
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=175d946ea00000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6d237e74cdc13f036473@syzkaller.appspotmail.com
>
> usb 3-1: Direct firmware load for isl3887usb failed with error -2
> usb 3-1: Firmware not found.
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in p54u_load_firmware_cb.cold+0x97/0x13d
> drivers/net/wireless/intersil/p54/p54usb.c:936
> Read of size 8 at addr ffff8881c9cf7588 by task kworker/1:5/2759
>
> CPU: 1 PID: 2759 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #11
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: events request_firmware_work_func
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0xca/0x13e lib/dump_stack.c:113
> print_address_description+0x67/0x231 mm/kasan/report.c:188
> __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
> kasan_report+0xe/0x20 mm/kasan/common.c:614
> p54u_load_firmware_cb.cold+0x97/0x13d
> drivers/net/wireless/intersil/p54/p54usb.c:936
> request_firmware_work_func+0x126/0x242
> drivers/base/firmware_loader/main.c:785
> process_one_work+0x905/0x1570 kernel/workqueue.c:2269
> worker_thread+0x96/0xe20 kernel/workqueue.c:2415
> kthread+0x30b/0x410 kernel/kthread.c:255
> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
>
> Allocated by task 1612:
> save_stack+0x1b/0x80 mm/kasan/common.c:71
> set_track mm/kasan/common.c:79 [inline]
> __kasan_kmalloc mm/kasan/common.c:489 [inline]
> __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:462
> kmalloc include/linux/slab.h:547 [inline]
> syslog_print kernel/printk/printk.c:1346 [inline]
> do_syslog kernel/printk/printk.c:1519 [inline]
> do_syslog+0x4f4/0x12e0 kernel/printk/printk.c:1493
> kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
> proc_reg_read+0x1c1/0x280 fs/proc/inode.c:221
> __vfs_read+0x76/0x100 fs/read_write.c:425
> vfs_read+0x18e/0x3d0 fs/read_write.c:461
> ksys_read+0x127/0x250 fs/read_write.c:587
> do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 1612:
> save_stack+0x1b/0x80 mm/kasan/common.c:71
> set_track mm/kasan/common.c:79 [inline]
> __kasan_slab_free+0x130/0x180 mm/kasan/common.c:451
> slab_free_hook mm/slub.c:1421 [inline]
> slab_free_freelist_hook mm/slub.c:1448 [inline]
> slab_free mm/slub.c:2994 [inline]
> kfree+0xd7/0x280 mm/slub.c:3949
> syslog_print kernel/printk/printk.c:1405 [inline]
> do_syslog kernel/printk/printk.c:1519 [inline]
> do_syslog+0xff3/0x12e0 kernel/printk/printk.c:1493
> kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
> proc_reg_read+0x1c1/0x280 fs/proc/inode.c:221
> __vfs_read+0x76/0x100 fs/read_write.c:425
> vfs_read+0x18e/0x3d0 fs/read_write.c:461
> ksys_read+0x127/0x250 fs/read_write.c:587
> do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff8881c9cf7180
> which belongs to the cache kmalloc-1k of size 1024
> The buggy address is located 8 bytes to the right of
> 1024-byte region [ffff8881c9cf7180, ffff8881c9cf7580)
> The buggy address belongs to the page:
> page:ffffea0007273d00 refcount:1 mapcount:0 mapping:ffff8881dac02a00
> index:0x0 compound_mapcount: 0
> flags: 0x200000000010200(slab|head)
> raw: 0200000000010200 dead000000000100 dead000000000200 ffff8881dac02a00
> raw: 0000000000000000 00000000000e000e 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8881c9cf7480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881c9cf7500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff8881c9cf7580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ^
> ffff8881c9cf7600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881c9cf7680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
Isn't this the same as syzkaller bug 200d4bb11b23d929335f ? Doesn't
the same patch fix it?
Alan Stern
^ permalink raw reply
* [PATCH] staging: wilc1000: add passive scan support
From: Adham.Abozaeid @ 2019-06-20 19:54 UTC (permalink / raw)
To: linux-wireless; +Cc: devel, gregkh, johannes, Ajay.Kathat, Adham.Abozaeid
From: Adham Abozaeid <adham.abozaeid@microchip.com>
Add passive scan support to the driver by passing the scan type to the
HW and configure the HW scan time if configured by the cfg80211.
Signed-off-by: Adham Abozaeid <adham.abozaeid@microchip.com>
---
drivers/staging/wilc1000/host_interface.c | 18 +++++++++++++++---
drivers/staging/wilc1000/host_interface.h | 1 -
.../staging/wilc1000/wilc_wfi_cfgoperations.c | 12 +++++++++---
drivers/staging/wilc1000/wilc_wlan_if.h | 2 +-
4 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c
index ed15bd1bcd56..13c9915358d0 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -6,7 +6,7 @@
#include "wilc_wfi_netdevice.h"
-#define WILC_HIF_SCAN_TIMEOUT_MS 4000
+#define WILC_HIF_SCAN_TIMEOUT_MS 5000
#define WILC_HIF_CONNECT_TIMEOUT_MS 9500
#define WILC_FALSE_FRMWR_CHANNEL 100
@@ -237,7 +237,7 @@ int wilc_scan(struct wilc_vif *vif, u8 scan_source, u8 scan_type,
int result = 0;
struct wid wid_list[5];
u32 index = 0;
- u32 i;
+ u32 i, scan_timeout;
u8 *buffer;
u8 valuesize = 0;
u8 *search_ssid_vals = NULL;
@@ -293,6 +293,18 @@ int wilc_scan(struct wilc_vif *vif, u8 scan_source, u8 scan_type,
wid_list[index].val = (s8 *)&scan_type;
index++;
+ if (scan_type == WILC_FW_PASSIVE_SCAN && request->duration) {
+ wid_list[index].id = WID_PASSIVE_SCAN_TIME;
+ wid_list[index].type = WID_SHORT;
+ wid_list[index].size = sizeof(u16);
+ wid_list[index].val = (s8 *)&request->duration;
+ index++;
+
+ scan_timeout = (request->duration * ch_list_len) + 500;
+ } else {
+ scan_timeout = WILC_HIF_SCAN_TIMEOUT_MS;
+ }
+
wid_list[index].id = WID_SCAN_CHANNEL_LIST;
wid_list[index].type = WID_BIN_DATA;
@@ -326,7 +338,7 @@ int wilc_scan(struct wilc_vif *vif, u8 scan_source, u8 scan_type,
hif_drv->scan_timer_vif = vif;
mod_timer(&hif_drv->scan_timer,
- jiffies + msecs_to_jiffies(WILC_HIF_SCAN_TIMEOUT_MS));
+ jiffies + msecs_to_jiffies(scan_timeout));
error:
diff --git a/drivers/staging/wilc1000/host_interface.h b/drivers/staging/wilc1000/host_interface.h
index a907c6d33012..4fcc7a3c151d 100644
--- a/drivers/staging/wilc1000/host_interface.h
+++ b/drivers/staging/wilc1000/host_interface.h
@@ -115,7 +115,6 @@ struct wilc_rcvd_net_info {
struct ieee80211_mgmt *mgmt;
};
-
struct wilc_user_scan_req {
void (*scan_result)(enum scan_event evt,
struct wilc_rcvd_net_info *info, void *priv);
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index f6825727bf77..b0daa1136663 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -221,6 +221,7 @@ static int scan(struct wiphy *wiphy, struct cfg80211_scan_request *request)
u32 i;
int ret = 0;
u8 scan_ch_list[WILC_MAX_NUM_SCANNED_CH];
+ u8 scan_type;
if (request->n_channels > WILC_MAX_NUM_SCANNED_CH) {
netdev_err(priv->dev, "Requested scanned channels over\n");
@@ -235,9 +236,14 @@ static int scan(struct wiphy *wiphy, struct cfg80211_scan_request *request)
scan_ch_list[i] = ieee80211_frequency_to_channel(freq);
}
- ret = wilc_scan(vif, WILC_FW_USER_SCAN, WILC_FW_ACTIVE_SCAN,
- scan_ch_list, request->n_channels, cfg_scan_result,
- (void *)priv, request);
+ if (request->n_ssids)
+ scan_type = WILC_FW_ACTIVE_SCAN;
+ else
+ scan_type = WILC_FW_PASSIVE_SCAN;
+
+ ret = wilc_scan(vif, WILC_FW_USER_SCAN, scan_type, scan_ch_list,
+ request->n_channels, cfg_scan_result, (void *)priv,
+ request);
if (ret) {
priv->scan_req = NULL;
diff --git a/drivers/staging/wilc1000/wilc_wlan_if.h b/drivers/staging/wilc1000/wilc_wlan_if.h
index b15de36e32e0..b89d0e0f04cc 100644
--- a/drivers/staging/wilc1000/wilc_wlan_if.h
+++ b/drivers/staging/wilc1000/wilc_wlan_if.h
@@ -684,7 +684,7 @@ enum {
WID_LONG_RETRY_LIMIT = 0x1003,
WID_BEACON_INTERVAL = 0x1006,
WID_MEMORY_ACCESS_16BIT = 0x1008,
-
+ WID_PASSIVE_SCAN_TIME = 0x100D,
WID_JOIN_START_TIMEOUT = 0x100F,
WID_ASOC_TIMEOUT = 0x1011,
WID_11I_PROTOCOL_TIMEOUT = 0x1012,
--
2.17.1
^ permalink raw reply related
* Re: KASAN: slab-out-of-bounds Read in p54u_load_firmware_cb
From: Christian Lamparter @ 2019-06-20 19:56 UTC (permalink / raw)
To: Alan Stern
Cc: syzbot, andreyknvl, chunkeey, davem, kvalo,
Kernel development list, USB list, linux-wireless, netdev,
syzkaller-bugs
In-Reply-To: <Pine.LNX.4.44L0.1906201544001.1346-100000@iolanthe.rowland.org>
On Thursday, June 20, 2019 9:46:32 PM CEST Alan Stern wrote:
> On Wed, 19 Jun 2019, syzbot wrote:
>
> > syzbot has found a reproducer for the following crash on:
> >
> > HEAD commit: 9939f56e usb-fuzzer: main usb gadget fuzzer driver
> > git tree: https://github.com/google/kasan.git usb-fuzzer
> > console output: https://syzkaller.appspot.com/x/log.txt?x=135e29faa00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=df134eda130bb43a
> > dashboard link: https://syzkaller.appspot.com/bug?extid=6d237e74cdc13f036473
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=175d946ea00000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+6d237e74cdc13f036473@syzkaller.appspotmail.com
> >
> > usb 3-1: Direct firmware load for isl3887usb failed with error -2
> > usb 3-1: Firmware not found.
> > ==================================================================
> > BUG: KASAN: slab-out-of-bounds in p54u_load_firmware_cb.cold+0x97/0x13d
> > drivers/net/wireless/intersil/p54/p54usb.c:936
> > Read of size 8 at addr ffff8881c9cf7588 by task kworker/1:5/2759
> >
> > CPU: 1 PID: 2759 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #11
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Workqueue: events request_firmware_work_func
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0xca/0x13e lib/dump_stack.c:113
> > print_address_description+0x67/0x231 mm/kasan/report.c:188
> > __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
> > kasan_report+0xe/0x20 mm/kasan/common.c:614
> > p54u_load_firmware_cb.cold+0x97/0x13d
> > drivers/net/wireless/intersil/p54/p54usb.c:936
> > request_firmware_work_func+0x126/0x242
> > drivers/base/firmware_loader/main.c:785
> > process_one_work+0x905/0x1570 kernel/workqueue.c:2269
> > worker_thread+0x96/0xe20 kernel/workqueue.c:2415
> > kthread+0x30b/0x410 kernel/kthread.c:255
> > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> >
> > Allocated by task 1612:
> > save_stack+0x1b/0x80 mm/kasan/common.c:71
> > set_track mm/kasan/common.c:79 [inline]
> > __kasan_kmalloc mm/kasan/common.c:489 [inline]
> > __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:462
> > kmalloc include/linux/slab.h:547 [inline]
> > syslog_print kernel/printk/printk.c:1346 [inline]
> > do_syslog kernel/printk/printk.c:1519 [inline]
> > do_syslog+0x4f4/0x12e0 kernel/printk/printk.c:1493
> > kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
> > proc_reg_read+0x1c1/0x280 fs/proc/inode.c:221
> > __vfs_read+0x76/0x100 fs/read_write.c:425
> > vfs_read+0x18e/0x3d0 fs/read_write.c:461
> > ksys_read+0x127/0x250 fs/read_write.c:587
> > do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > Freed by task 1612:
> > save_stack+0x1b/0x80 mm/kasan/common.c:71
> > set_track mm/kasan/common.c:79 [inline]
> > __kasan_slab_free+0x130/0x180 mm/kasan/common.c:451
> > slab_free_hook mm/slub.c:1421 [inline]
> > slab_free_freelist_hook mm/slub.c:1448 [inline]
> > slab_free mm/slub.c:2994 [inline]
> > kfree+0xd7/0x280 mm/slub.c:3949
> > syslog_print kernel/printk/printk.c:1405 [inline]
> > do_syslog kernel/printk/printk.c:1519 [inline]
> > do_syslog+0xff3/0x12e0 kernel/printk/printk.c:1493
> > kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
> > proc_reg_read+0x1c1/0x280 fs/proc/inode.c:221
> > __vfs_read+0x76/0x100 fs/read_write.c:425
> > vfs_read+0x18e/0x3d0 fs/read_write.c:461
> > ksys_read+0x127/0x250 fs/read_write.c:587
> > do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > The buggy address belongs to the object at ffff8881c9cf7180
> > which belongs to the cache kmalloc-1k of size 1024
> > The buggy address is located 8 bytes to the right of
> > 1024-byte region [ffff8881c9cf7180, ffff8881c9cf7580)
> > The buggy address belongs to the page:
> > page:ffffea0007273d00 refcount:1 mapcount:0 mapping:ffff8881dac02a00
> > index:0x0 compound_mapcount: 0
> > flags: 0x200000000010200(slab|head)
> > raw: 0200000000010200 dead000000000100 dead000000000200 ffff8881dac02a00
> > raw: 0000000000000000 00000000000e000e 00000001ffffffff 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff8881c9cf7480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff8881c9cf7500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > > ffff8881c9cf7580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ^
> > ffff8881c9cf7600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff8881c9cf7680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ==================================================================
>
> Isn't this the same as syzkaller bug 200d4bb11b23d929335f ? Doesn't
> the same patch fix it?
>
I think Kalle hasn't applied it yet? It's still sitting on the patchwork queue:
<https://patchwork.kernel.org/patch/10951527/>
Regards,
Christian
^ permalink raw reply
* Re: [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
From: Denis Kenzior @ 2019-06-20 20:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <44923833f1068e360b1f9534a9bbd37be41e4833.camel@sipsolutions.net>
Hi Johannes,
On 06/20/2019 02:17 PM, Johannes Berg wrote:
> Hi Denis,
>
>>> We generally can't add anything to any of the cases before the split was
>>> allowed, for compatibility with old userspace.
>>
>> Can you educate me here? Is it because the non-split dump messages would
>> grow too large?
>
> No. Those messages aren't really relevant, userspace will need to do a
> larger buffer for it.
>
> The problem is that old userspace (like really old) didn't split even
> dumps. Eventually, we had so much information here that the default dump
> message size is exceeded, and we simply couldn't dump that particular
> wiphy anymore.
>
> We solved this by splitting the wiphy information into multiple
> messages, but that needed new userspace, so when userspace doesn't
> request split dumps, we fall through all the way to "case 8" and then
> stop - old userspace cannot care about new information anyway.
>
> The reason it was split into cases 0-8 that are combined in non-split
> dumps is that it was safer that way - there were certain configurations
> where even the original data would go above the message size limit.
Ugh. So, if I understand this correctly, NEW_WIPHY events that are
generated when a new wiphy is plugged would only send the old 'legacy'
info and any info we add in cases 9+ would be 'lost' and the application
is forced into re-dumping the phy. This is pretty much counter to what
we want.
If you want to keep your sanity in userspace, you need proper 'object
appeared' / 'object disappeared' events from the kernel. And those
events should have all or nearly all info to not bother the kernel going
forward. It sounds like nl80211 API has run into the extend-ability
wall, no?
Any suggestions on how to resolve this? Should NEW_WIPHY events also do
the whole split_dump semantic and generate 15+ or whatever messages?
Regards,
-Denis
^ permalink raw reply
* Re: [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
From: Johannes Berg @ 2019-06-20 20:09 UTC (permalink / raw)
To: Denis Kenzior; +Cc: linux-wireless
In-Reply-To: <427f488f-98f5-f888-f079-e2bbbb6eedf3@gmail.com>
On Thu, 2019-06-20 at 15:05 -0500, Denis Kenzior wrote:
>
> Ugh. So, if I understand this correctly, NEW_WIPHY events that are
> generated when a new wiphy is plugged would only send the old 'legacy'
> info and any info we add in cases 9+ would be 'lost' and the application
> is forced into re-dumping the phy.
Yes.
> This is pretty much counter to what we want.
Well, you want the info, shouldn't matter how you get it?
> If you want to keep your sanity in userspace, you need proper 'object
> appeared' / 'object disappeared' events from the kernel.
Sure, but you don't really need to know *everything* about the events
right there ... you can already filter which ones you care about
(perhaps you know you never want to bind hwsim ones for example) and
then request data on those that you do need.
> And those
> events should have all or nearly all info to not bother the kernel going
> forward.
That's what you wish for, but ...
> It sounds like nl80211 API has run into the extend-ability
> wall, no?
I don't really see it that way.
> Any suggestions on how to resolve this? Should NEW_WIPHY events also do
> the whole split_dump semantic and generate 15+ or whatever messages?
No, that'd be awful, and anyway you'd have to send a new command because
otherwise old applications might be completely confused (not that I know
of any other than "iw event" that would event listen to this, but who
knows)
johannes
^ permalink raw reply
* Re: [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
From: Johannes Berg @ 2019-06-20 20:21 UTC (permalink / raw)
To: Denis Kenzior; +Cc: linux-wireless
In-Reply-To: <144f36779085498bdc1b2f7ac0d0c267d431f51d.camel@sipsolutions.net>
On Thu, 2019-06-20 at 22:09 +0200, Johannes Berg wrote:
>
> Sure, but you don't really need to know *everything* about the events
> right there ... you can already filter which ones you care about
> (perhaps you know you never want to bind hwsim ones for example) and
> then request data on those that you do need.
Btw, you can send a filter down when you do request the data, so you
only get the data for the new wiphy you actually just discovered.
So realistically, vs. your suggestion of sending all of the data in
multiple events, that just adds 2 messages (the request and the data you
already had), which isn't nearly as bad as you paint it.
johannes
^ permalink raw reply
* Re: [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
From: Denis Kenzior @ 2019-06-20 20:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <144f36779085498bdc1b2f7ac0d0c267d431f51d.camel@sipsolutions.net>
Hi Johannes,
On 06/20/2019 03:09 PM, Johannes Berg wrote:
> On Thu, 2019-06-20 at 15:05 -0500, Denis Kenzior wrote:
>>
>> Ugh. So, if I understand this correctly, NEW_WIPHY events that are
>> generated when a new wiphy is plugged would only send the old 'legacy'
>> info and any info we add in cases 9+ would be 'lost' and the application
>> is forced into re-dumping the phy.
>
> Yes.
>
>> This is pretty much counter to what we want.
>
> Well, you want the info, shouldn't matter how you get it?
>
Well, it kind of does. You're asking userspace to introduce extra
complexity, extra round trips, extra stuff to go wrong just because the
kernel API has painted itself into a corner.
>> If you want to keep your sanity in userspace, you need proper 'object
>> appeared' / 'object disappeared' events from the kernel.
>
> Sure, but you don't really need to know *everything* about the events
> right there ... you can already filter which ones you care about
> (perhaps you know you never want to bind hwsim ones for example) and
> then request data on those that you do need.
Sure, but it would be nice to have all the info available if we do not
want to filter it...
>
>> And those
>> events should have all or nearly all info to not bother the kernel going
>> forward.
>
> That's what you wish for, but ...
Well, it is a pretty basic requirement for any event driven API, no?
>
>> It sounds like nl80211 API has run into the extend-ability
>> wall, no?
>
> I don't really see it that way.
>
>> Any suggestions on how to resolve this? Should NEW_WIPHY events also do
>> the whole split_dump semantic and generate 15+ or whatever messages?
>
> No, that'd be awful, and anyway you'd have to send a new command because
> otherwise old applications might be completely confused (not that I know
> of any other than "iw event" that would event listen to this, but who
> knows)
Well, given that we're the only ones that seem to care about this right
now, I don't see sending a new command as much of a big deal. I welcome
other ideas, but having the kernel send us an event, then us turning
around and requesting the *same* info is just silly.
Regards,
-Denis
^ permalink raw reply
* [PATCH v2 1/3] nl80211: Update uapi for CMD_FRAME_WAIT_CANCEL
From: Denis Kenzior @ 2019-06-20 22:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Denis Kenzior
Commit 1c38c7f22068 ("nl80211: send event when CMD_FRAME duration
expires") added the possibility of NL80211_CMD_FRAME_WAIT_CANCEL
being sent whenever the off-channel wait time associated with a
CMD_FRAME completes. Document this in the uapi/linux/nl80211.h file.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
---
include/uapi/linux/nl80211.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Changes in v2:
- update commit formatting
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 8fc3a43cac75..0d9aad98c983 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -657,7 +657,9 @@
* is used during CSA period.
* @NL80211_CMD_FRAME_WAIT_CANCEL: When an off-channel TX was requested, this
* command may be used with the corresponding cookie to cancel the wait
- * time if it is known that it is no longer necessary.
+ * time if it is known that it is no longer necessary. This command is
+ * also sent as an event whenever the driver has completed the off-channel
+ * wait time.
* @NL80211_CMD_ACTION: Alias for @NL80211_CMD_FRAME for backward compatibility.
* @NL80211_CMD_FRAME_TX_STATUS: Report TX status of a management frame
* transmitted with %NL80211_CMD_FRAME. %NL80211_ATTR_COOKIE identifies
--
2.21.0
^ permalink raw reply related
* [PATCH v2 2/3] nl80211: Limit certain commands to interface owner
From: Denis Kenzior @ 2019-06-20 22:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Denis Kenzior
In-Reply-To: <20190620220749.10071-1-denkenz@gmail.com>
If the wdev object has been created (via NEW_INTERFACE) with
SOCKET_OWNER attribute set, then limit certain commands only to the
process that created that wdev.
This can be used to make sure no other process on the system interferes
by sending unwanted scans, action frames or any other funny business.
This patch introduces a new internal flag, and checks that flag in the
pre_doit hook.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
---
net/wireless/nl80211.c | 80 ++++++++++++++++++++++++++++++++----------
1 file changed, 61 insertions(+), 19 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ff760ba83449..26bab9560c0f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -13587,6 +13587,7 @@ static int nl80211_probe_mesh_link(struct sk_buff *skb, struct genl_info *info)
#define NL80211_FLAG_NEED_WDEV_UP (NL80211_FLAG_NEED_WDEV |\
NL80211_FLAG_CHECK_NETDEV_UP)
#define NL80211_FLAG_CLEAR_SKB 0x20
+#define NL80211_FLAG_OWNER_ONLY 0x40
static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
struct genl_info *info)
@@ -13595,6 +13596,7 @@ static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
struct wireless_dev *wdev;
struct net_device *dev;
bool rtnl = ops->internal_flags & NL80211_FLAG_NEED_RTNL;
+ int ret;
if (rtnl)
rtnl_lock();
@@ -13602,10 +13604,10 @@ static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
if (ops->internal_flags & NL80211_FLAG_NEED_WIPHY) {
rdev = cfg80211_get_dev_from_info(genl_info_net(info), info);
if (IS_ERR(rdev)) {
- if (rtnl)
- rtnl_unlock();
- return PTR_ERR(rdev);
+ ret = PTR_ERR(rdev);
+ goto done;
}
+
info->user_ptr[0] = rdev;
} else if (ops->internal_flags & NL80211_FLAG_NEED_NETDEV ||
ops->internal_flags & NL80211_FLAG_NEED_WDEV) {
@@ -13614,32 +13616,33 @@ static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
wdev = __cfg80211_wdev_from_attrs(genl_info_net(info),
info->attrs);
if (IS_ERR(wdev)) {
- if (rtnl)
- rtnl_unlock();
- return PTR_ERR(wdev);
+ ret = PTR_ERR(wdev);
+ goto done;
}
dev = wdev->netdev;
rdev = wiphy_to_rdev(wdev->wiphy);
+ ret = -EINVAL;
if (ops->internal_flags & NL80211_FLAG_NEED_NETDEV) {
- if (!dev) {
- if (rtnl)
- rtnl_unlock();
- return -EINVAL;
- }
+ if (!dev)
+ goto done;
info->user_ptr[1] = dev;
} else {
info->user_ptr[1] = wdev;
}
+ ret = -ENETDOWN;
if (ops->internal_flags & NL80211_FLAG_CHECK_NETDEV_UP &&
- !wdev_running(wdev)) {
- if (rtnl)
- rtnl_unlock();
- return -ENETDOWN;
- }
+ !wdev_running(wdev))
+ goto done;
+
+ ret = -EPERM;
+ if (ops->internal_flags & NL80211_FLAG_OWNER_ONLY &&
+ wdev->owner_nlportid &&
+ wdev->owner_nlportid != info->snd_portid)
+ goto done;
if (dev)
dev_hold(dev);
@@ -13647,7 +13650,13 @@ static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
info->user_ptr[0] = rdev;
}
- return 0;
+ ret = 0;
+
+done:
+ if (rtnl && !ret)
+ rtnl_unlock();
+
+ return ret;
}
static void nl80211_post_doit(const struct genl_ops *ops, struct sk_buff *skb,
@@ -13712,7 +13721,8 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_set_interface,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV |
- NL80211_FLAG_NEED_RTNL,
+ NL80211_FLAG_NEED_RTNL |
+ NL80211_FLAG_OWNER_ONLY,
},
{
.cmd = NL80211_CMD_NEW_INTERFACE,
@@ -13728,7 +13738,8 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_del_interface,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV |
- NL80211_FLAG_NEED_RTNL,
+ NL80211_FLAG_NEED_RTNL |
+ NL80211_FLAG_OWNER_ONLY,
},
{
.cmd = NL80211_CMD_GET_KEY,
@@ -13745,6 +13756,7 @@ static const struct genl_ops nl80211_ops[] = {
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_CLEAR_SKB,
},
{
@@ -13754,6 +13766,7 @@ static const struct genl_ops nl80211_ops[] = {
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_CLEAR_SKB,
},
{
@@ -13762,6 +13775,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_del_key,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13778,6 +13792,7 @@ static const struct genl_ops nl80211_ops[] = {
.flags = GENL_UNS_ADMIN_PERM,
.doit = nl80211_start_ap,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13786,6 +13801,7 @@ static const struct genl_ops nl80211_ops[] = {
.flags = GENL_UNS_ADMIN_PERM,
.doit = nl80211_stop_ap,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13802,6 +13818,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_set_station,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13810,6 +13827,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_new_station,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13818,6 +13836,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_del_station,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13921,6 +13940,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_trigger_scan,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13929,6 +13949,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_abort_scan,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13942,6 +13963,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_start_sched_scan,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13950,6 +13972,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_stop_sched_scan,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13958,6 +13981,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_authenticate,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL |
NL80211_FLAG_CLEAR_SKB,
},
@@ -13967,6 +13991,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_associate,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL |
NL80211_FLAG_CLEAR_SKB,
},
@@ -13976,6 +14001,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_deauthenticate,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13984,6 +14010,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_disassociate,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13992,6 +14019,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_join_ibss,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14000,6 +14028,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_leave_ibss,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
#ifdef CONFIG_NL80211_TESTMODE
@@ -14019,6 +14048,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_connect,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL |
NL80211_FLAG_CLEAR_SKB,
},
@@ -14028,6 +14058,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_update_connect_params,
.flags = GENL_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL |
NL80211_FLAG_CLEAR_SKB,
},
@@ -14037,6 +14068,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_disconnect,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14083,6 +14115,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_remain_on_channel,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14091,6 +14124,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_cancel_remain_on_channel,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14115,6 +14149,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_tx_mgmt,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14123,6 +14158,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_tx_mgmt_cancel_wait,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14147,6 +14183,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_set_cqm,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14221,6 +14258,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_set_rekey_data,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL |
NL80211_FLAG_CLEAR_SKB,
},
@@ -14278,6 +14316,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_start_p2p_device,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14286,6 +14325,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_stop_p2p_device,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14371,6 +14411,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_crit_protocol_start,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14379,6 +14420,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_crit_protocol_stop,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
--
2.21.0
^ permalink raw reply related
* [PATCH v2 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
From: Denis Kenzior @ 2019-06-20 22:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Denis Kenzior
In-Reply-To: <20190620220749.10071-1-denkenz@gmail.com>
Include wiphy address setup in wiphy dumps and new wiphy events. The
wiphy permanent address is exposed as ATTR_MAC. If addr_mask is setup,
then it is included as ATTR_MAC_MASK attribute. If multiple addresses
are available, then their are exposed in a nested ATTR_MAC_ADDRS array.
This information is already exposed via sysfs, but it makes sense to
include it in the wiphy dump as well.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
---
net/wireless/nl80211.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
Changes in v2:
- Move from case 0 to 9
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 26bab9560c0f..f4b3e6f1dfbf 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2166,6 +2166,31 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
rdev->wiphy.vht_capa_mod_mask))
goto nla_put_failure;
+ if (nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN,
+ rdev->wiphy.perm_addr))
+ goto nla_put_failure;
+
+ if (!is_zero_ether_addr(rdev->wiphy.addr_mask) &&
+ nla_put(msg, NL80211_ATTR_MAC_MASK, ETH_ALEN,
+ rdev->wiphy.addr_mask))
+ goto nla_put_failure;
+
+ if (rdev->wiphy.n_addresses > 1) {
+ void *attr;
+
+ attr = nla_nest_start_noflag(msg,
+ NL80211_ATTR_MAC_ADDRS);
+ if (!attr)
+ goto nla_put_failure;
+
+ for (i = 0; i < rdev->wiphy.n_addresses; i++)
+ if (nla_put(msg, i + 1, ETH_ALEN,
+ rdev->wiphy.addresses[i].addr))
+ goto nla_put_failure;
+
+ nla_nest_end(msg, attr);
+ }
+
state->split_start++;
break;
case 10:
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
From: Denis Kenzior @ 2019-06-20 23:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <cc4f1755ee5f27c72cbac344988bcb91a1a835f3.camel@sipsolutions.net>
Hi Johannes,
On 06/20/2019 03:21 PM, Johannes Berg wrote:
> On Thu, 2019-06-20 at 22:09 +0200, Johannes Berg wrote:
>>
>> Sure, but you don't really need to know *everything* about the events
>> right there ... you can already filter which ones you care about
>> (perhaps you know you never want to bind hwsim ones for example) and
>> then request data on those that you do need.
>
> Btw, you can send a filter down when you do request the data, so you
> only get the data for the new wiphy you actually just discovered.
Yes, I know that. I did help fix this ~3 years ago in commit
b7fb44dacae04. Nobody was using that prior, which really leads me to
wonder what other userspace tools are doing for hotplug and how broken
they are...
>
> So realistically, vs. your suggestion of sending all of the data in
> multiple events, that just adds 2 messages (the request and the data you
> already had), which isn't nearly as bad as you paint it.
I never 'painted' the message overhead as 'bad'. The performance
overhead of this ping-pong is probably irrelevant in the grand scheme of
things. But I find the approach inelegant.
But really I'm more worried about race conditions that userspace has to
deal with. We already have the weird case of ATTR_GENERATION (which
nobody actually uses btw). And then we also need to dump both the
wiphys and the interfaces separately, cross-reference them while dealing
with the possibility of a wiphy or interface going away or being added
at any point. Then there's the fact that some drivers always add a
default netdev, others that (possibly) don't and the possibility that
the system was left in a weird state.
So from that standpoint it is far better to have the kernel generate
atomic change events with all the info present than having userspace
re-poll it when stuff might have changed in the meantime.
Going back to your 2 message point. What about sending the 'NEW_WIPHY'
event with the info in labels 0-8. And then another event type with the
'rest' of the info. And perhaps another feature bit to tell userspace
to expect multiple events. That would still end up being 2 messages and
still be more efficient than the ping-pong you suggest.
Regards,
-Denis
^ permalink raw reply
* Re: [PATCH v2 2/3] nl80211: Limit certain commands to interface owner
From: Arend Van Spriel @ 2019-06-21 8:09 UTC (permalink / raw)
To: Denis Kenzior, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <20190620220749.10071-2-denkenz@gmail.com>
On 6/21/2019 12:07 AM, Denis Kenzior wrote:
> If the wdev object has been created (via NEW_INTERFACE) with
> SOCKET_OWNER attribute set, then limit certain commands only to the
> process that created that wdev.
>
> This can be used to make sure no other process on the system interferes
> by sending unwanted scans, action frames or any other funny business.
The flag is a good addition opposed to having handlers deal with it.
However, earlier motivation for SOCKET_OWNER use was about netlink
multicast being unreliable, which I can agree to. However, avoiding
"funny business" is a different thing. Our testing infrastructure is
doing all kind of funny business. Guess we will need to refrain from
using any user-space wireless tools that use the SOCKET_OWNER attribute,
but how do we know? Somehow I suspect iwd is one to avoid ;-) I have yet
to give iwd a spin, but this SOCKET_OWNER strategy kept me from it.
Maybe iwd could have a developer option which disables the use of the
SOCKET_OWNER attribute.
Regards,
Arend
> This patch introduces a new internal flag, and checks that flag in the
> pre_doit hook.
>
> Signed-off-by: Denis Kenzior <denkenz@gmail.com>
> ---
> net/wireless/nl80211.c | 80 ++++++++++++++++++++++++++++++++----------
> 1 file changed, 61 insertions(+), 19 deletions(-)
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index ff760ba83449..26bab9560c0f 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -13587,6 +13587,7 @@ static int nl80211_probe_mesh_link(struct sk_buff *skb, struct genl_info *info)
> #define NL80211_FLAG_NEED_WDEV_UP (NL80211_FLAG_NEED_WDEV |\
> NL80211_FLAG_CHECK_NETDEV_UP)
> #define NL80211_FLAG_CLEAR_SKB 0x20
> +#define NL80211_FLAG_OWNER_ONLY 0x40
>
> static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
> struct genl_info *info)
> @@ -13595,6 +13596,7 @@ static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
> struct wireless_dev *wdev;
> struct net_device *dev;
> bool rtnl = ops->internal_flags & NL80211_FLAG_NEED_RTNL;
> + int ret;
>
> if (rtnl)
> rtnl_lock();
> @@ -13602,10 +13604,10 @@ static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
> if (ops->internal_flags & NL80211_FLAG_NEED_WIPHY) {
> rdev = cfg80211_get_dev_from_info(genl_info_net(info), info);
> if (IS_ERR(rdev)) {
> - if (rtnl)
> - rtnl_unlock();
> - return PTR_ERR(rdev);
> + ret = PTR_ERR(rdev);
> + goto done;
> }
> +
> info->user_ptr[0] = rdev;
> } else if (ops->internal_flags & NL80211_FLAG_NEED_NETDEV ||
> ops->internal_flags & NL80211_FLAG_NEED_WDEV) {
> @@ -13614,32 +13616,33 @@ static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
> wdev = __cfg80211_wdev_from_attrs(genl_info_net(info),
> info->attrs);
> if (IS_ERR(wdev)) {
> - if (rtnl)
> - rtnl_unlock();
> - return PTR_ERR(wdev);
> + ret = PTR_ERR(wdev);
> + goto done;
> }
>
> dev = wdev->netdev;
> rdev = wiphy_to_rdev(wdev->wiphy);
>
> + ret = -EINVAL;
> if (ops->internal_flags & NL80211_FLAG_NEED_NETDEV) {
> - if (!dev) {
> - if (rtnl)
> - rtnl_unlock();
> - return -EINVAL;
> - }
> + if (!dev)
> + goto done;
>
> info->user_ptr[1] = dev;
> } else {
> info->user_ptr[1] = wdev;
> }
>
> + ret = -ENETDOWN;
> if (ops->internal_flags & NL80211_FLAG_CHECK_NETDEV_UP &&
> - !wdev_running(wdev)) {
> - if (rtnl)
> - rtnl_unlock();
> - return -ENETDOWN;
> - }
> + !wdev_running(wdev))
> + goto done;
> +
> + ret = -EPERM;
> + if (ops->internal_flags & NL80211_FLAG_OWNER_ONLY &&
> + wdev->owner_nlportid &&
> + wdev->owner_nlportid != info->snd_portid)
> + goto done;
>
> if (dev)
> dev_hold(dev);
> @@ -13647,7 +13650,13 @@ static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
> info->user_ptr[0] = rdev;
> }
>
> - return 0;
> + ret = 0;
> +
> +done:
> + if (rtnl && !ret)
> + rtnl_unlock();
> +
> + return ret;
> }
>
> static void nl80211_post_doit(const struct genl_ops *ops, struct sk_buff *skb,
> @@ -13712,7 +13721,8 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_set_interface,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV |
> - NL80211_FLAG_NEED_RTNL,
> + NL80211_FLAG_NEED_RTNL |
> + NL80211_FLAG_OWNER_ONLY,
> },
> {
> .cmd = NL80211_CMD_NEW_INTERFACE,
> @@ -13728,7 +13738,8 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_del_interface,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_WDEV |
> - NL80211_FLAG_NEED_RTNL,
> + NL80211_FLAG_NEED_RTNL |
> + NL80211_FLAG_OWNER_ONLY,
> },
> {
> .cmd = NL80211_CMD_GET_KEY,
> @@ -13745,6 +13756,7 @@ static const struct genl_ops nl80211_ops[] = {
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> NL80211_FLAG_NEED_RTNL |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_CLEAR_SKB,
> },
> {
> @@ -13754,6 +13766,7 @@ static const struct genl_ops nl80211_ops[] = {
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> NL80211_FLAG_NEED_RTNL |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_CLEAR_SKB,
> },
> {
> @@ -13762,6 +13775,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_del_key,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -13778,6 +13792,7 @@ static const struct genl_ops nl80211_ops[] = {
> .flags = GENL_UNS_ADMIN_PERM,
> .doit = nl80211_start_ap,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -13786,6 +13801,7 @@ static const struct genl_ops nl80211_ops[] = {
> .flags = GENL_UNS_ADMIN_PERM,
> .doit = nl80211_stop_ap,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -13802,6 +13818,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_set_station,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -13810,6 +13827,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_new_station,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -13818,6 +13836,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_del_station,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -13921,6 +13940,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_trigger_scan,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_WDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -13929,6 +13949,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_abort_scan,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_WDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -13942,6 +13963,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_start_sched_scan,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -13950,6 +13972,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_stop_sched_scan,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -13958,6 +13981,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_authenticate,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL |
> NL80211_FLAG_CLEAR_SKB,
> },
> @@ -13967,6 +13991,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_associate,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL |
> NL80211_FLAG_CLEAR_SKB,
> },
> @@ -13976,6 +14001,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_deauthenticate,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -13984,6 +14010,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_disassociate,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -13992,6 +14019,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_join_ibss,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -14000,6 +14028,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_leave_ibss,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> #ifdef CONFIG_NL80211_TESTMODE
> @@ -14019,6 +14048,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_connect,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL |
> NL80211_FLAG_CLEAR_SKB,
> },
> @@ -14028,6 +14058,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_update_connect_params,
> .flags = GENL_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL |
> NL80211_FLAG_CLEAR_SKB,
> },
> @@ -14037,6 +14068,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_disconnect,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -14083,6 +14115,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_remain_on_channel,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_WDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -14091,6 +14124,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_cancel_remain_on_channel,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_WDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -14115,6 +14149,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_tx_mgmt,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_WDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -14123,6 +14158,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_tx_mgmt_cancel_wait,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_WDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -14147,6 +14183,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_set_cqm,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -14221,6 +14258,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_set_rekey_data,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL |
> NL80211_FLAG_CLEAR_SKB,
> },
> @@ -14278,6 +14316,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_start_p2p_device,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_WDEV |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -14286,6 +14325,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_stop_p2p_device,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_WDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -14371,6 +14411,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_crit_protocol_start,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_WDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
> @@ -14379,6 +14420,7 @@ static const struct genl_ops nl80211_ops[] = {
> .doit = nl80211_crit_protocol_stop,
> .flags = GENL_UNS_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_WDEV_UP |
> + NL80211_FLAG_OWNER_ONLY |
> NL80211_FLAG_NEED_RTNL,
> },
> {
>
^ permalink raw reply
* Re: [PATCH] rt2x00: fix rx queue hang
From: Soeren Moch @ 2019-06-21 11:30 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Helmut Schaa, Kalle Valo, David S. Miller, linux-wireless, netdev,
linux-kernel, stable
In-Reply-To: <20190618093431.GA2577@redhat.com>
Hi!
On 18.06.19 11:34, Stanislaw Gruszka wrote:
> Hi
>
> On Mon, Jun 17, 2019 at 11:46:56AM +0200, Soeren Moch wrote:
>> Since commit ed194d136769 ("usb: core: remove local_irq_save() around
>> ->complete() handler") the handlers rt2x00usb_interrupt_rxdone() and
>> rt2x00usb_interrupt_txdone() are not running with interrupts disabled
>> anymore. So these handlers are not guaranteed to run completely before
>> workqueue processing starts. So only mark entries ready for workqueue
>> processing after proper accounting in the dma done queue.
> It was always the case on SMP machines that rt2x00usb_interrupt_{tx/rx}done
> can run concurrently with rt2x00_work_{rx,tx}done, so I do not
> understand how removing local_irq_save() around complete handler broke
> things.
I think because completion handlers can be interrupted now and scheduled
away
in the middle of processing.
> Have you reverted commit ed194d136769 and the revert does solve the problem ?
Yes, I already sent a patch for this, see [1]. But this was not considered
an acceptablesolution. Especially RT folks do not like code running with
interrupts disabled,particularly when trying to acquire spinlocks then.
[1] https://lkml.org/lkml/2019/5/31/863
> Between 4.19 and 4.20 we have some quite big changes in rt2x00 driver:
>
> 0240564430c0 rt2800: flush and txstatus rework for rt2800mmio
> adf26a356f13 rt2x00: use different txstatus timeouts when flushing
> 5022efb50f62 rt2x00: do not check for txstatus timeout every time on tasklet
> 0b0d556e0ebb rt2800mmio: use txdone/txstatus routines from lib
> 5c656c71b1bf rt2800: move usb specific txdone/txstatus routines to rt2800lib
>
> so I'm a bit afraid that one of those changes is real cause of
> the issue not ed194d136769 .
I tested 4.20 and 5.1 and see the exact same behavior. Reverting this
usb core patchsolves the problem.
4.19.x (before this usb core patch) is running fine.
>> Note that rt2x00usb_work_rxdone() processes all available entries, not
>> only such for which queue_work() was called.
>>
>> This fixes a regression on a RT5370 based wifi stick in AP mode, which
>> suddenly stopped data transmission after some period of heavy load. Also
>> stopping the hanging hostapd resulted in the error message "ieee80211
>> phy0: rt2x00queue_flush_queue: Warning - Queue 14 failed to flush".
>> Other operation modes are probably affected as well, this just was
>> the used testcase.
> Do you know what actually make the traffic stop,
> TX queue hung or RX queue hung?
I think RX queue hang, as stated in the patch title. "Queue 14" means QID_RX
(rt2x00queue.h, enum data_queue_qid).
I also tried to re-add local_irq_save() in only one of the handlers. Adding
this tort2x00usb_interrupt_rxdone() alone solved the issue, while doing so
for tx alonedid not.
Note that this doesn't mean there is no problem for tx, that's maybe
just more
difficult to trigger.
>> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
>> index 1b08b01db27b..9c102a501ee6 100644
>> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
>> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
>> @@ -263,9 +263,9 @@ EXPORT_SYMBOL_GPL(rt2x00lib_dmastart);
>>
>> void rt2x00lib_dmadone(struct queue_entry *entry)
>> {
>> - set_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags);
>> clear_bit(ENTRY_OWNER_DEVICE_DATA, &entry->flags);
>> rt2x00queue_index_inc(entry, Q_INDEX_DMA_DONE);
>> + set_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags);
> Unfortunately I do not understand how this suppose to fix the problem,
> could you elaborate more about this change?
>
Re-adding local_irq_save() around thisrt2x00lib_dmadone()solved
the issue. So I also tried to reverse the order of these calls.
It seems totally plausible to me, that the correct sequence is to
first clear the device assignment, then to set the status to dma_done,
then to trigger the workqueue processing for this entry. When the handler
is scheduled away in the middle of this sequence, now there is no
strange state where the entry can be processed by the workqueue while
not declared dma_done for it.
With this changed sequence there is no need anymore to disable interrupts
for solving the hang issue.
Regards,
Soeren
^ permalink raw reply
* Re: [PATCH v2 2/3] nl80211: Limit certain commands to interface owner
From: Marcel Holtmann @ 2019-06-21 13:27 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: Denis Kenzior, Johannes Berg, linux-wireless
In-Reply-To: <11852f40-67e5-9122-7d82-077bdd0b014a@broadcom.com>
Hi Arend,
>> If the wdev object has been created (via NEW_INTERFACE) with
>> SOCKET_OWNER attribute set, then limit certain commands only to the
>> process that created that wdev.
>> This can be used to make sure no other process on the system interferes
>> by sending unwanted scans, action frames or any other funny business.
>
> The flag is a good addition opposed to having handlers deal with it. However, earlier motivation for SOCKET_OWNER use was about netlink multicast being unreliable, which I can agree to. However, avoiding "funny business" is a different thing. Our testing infrastructure is doing all kind of funny business. Guess we will need to refrain from using any user-space wireless tools that use the SOCKET_OWNER attribute, but how do we know? Somehow I suspect iwd is one to avoid ;-) I have yet to give iwd a spin, but this SOCKET_OWNER strategy kept me from it. Maybe iwd could have a developer option which disables the use of the SOCKET_OWNER attribute.
when running iwd, we expect reproducible behavior. Meaning we need to ensure that nobody else is messing with our interfaces behind our back. A testing infrastructure that does that is really no good in the first place since you yourself are introducing unclean behavior.
When testing with iwd, we are testing the D-Bus API of iwd and you can at the same time take PCAP traces with iwmon. If we are able to store trace-cmd information also in the same PCAP file, we can extend iwmon to do exactly that. So far iwmon allows you to grab the netlink communication and the PAE communication which means you can easily analyze what was happening without having ask nl80211.
If you require extra debug information or triggers, then this has to happen via a D-Bus debug interfaces. However I see no benefit of not using SOCKET_OWNER. As I said above, if the testing uses different options than the real environment, what good is the testing.
Regards
Marcel
^ permalink raw reply
* [PATCH] mwifiex: ignore processing invalid command response
From: Ganapathi Bhat @ 2019-06-21 14:14 UTC (permalink / raw)
To: linux-wireless
Cc: Brian Norris, Cathy Luo, Zhiyuan Yang, James Cao, Rakesh Parmar,
Swati Kushwaha, Ganapathi Bhat
From: Swati Kushwaha <swatiuma@marvell.com>
Firmware can send invalid command response, the processing of
which can attempt to modify unexpected context and cause issues.
To fix this, driver should check that the command response ID is
same as the one it downloaded, and ignore processing of invalid
response.
Signed-off-by: Swati Kushwaha <swatiuma@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 27 ++++++++++++++++--------
drivers/net/wireless/marvell/mwifiex/main.h | 2 +-
2 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 8c35441..133b03d 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -39,10 +39,11 @@
static void
mwifiex_init_cmd_node(struct mwifiex_private *priv,
struct cmd_ctrl_node *cmd_node,
- u32 cmd_oid, void *data_buf, bool sync)
+ u32 cmd_no, void *data_buf, bool sync)
{
cmd_node->priv = priv;
- cmd_node->cmd_oid = cmd_oid;
+ cmd_node->cmd_no = cmd_no;
+
if (sync) {
cmd_node->wait_q_enabled = true;
cmd_node->cmd_wait_q_woken = false;
@@ -92,7 +93,7 @@
mwifiex_clean_cmd_node(struct mwifiex_adapter *adapter,
struct cmd_ctrl_node *cmd_node)
{
- cmd_node->cmd_oid = 0;
+ cmd_node->cmd_no = 0;
cmd_node->cmd_flag = 0;
cmd_node->data_buf = NULL;
cmd_node->wait_q_enabled = false;
@@ -201,6 +202,7 @@ static int mwifiex_dnld_cmd_to_fw(struct mwifiex_private *priv,
}
cmd_code = le16_to_cpu(host_cmd->command);
+ cmd_node->cmd_no = cmd_code;
cmd_size = le16_to_cpu(host_cmd->size);
if (adapter->hw_status == MWIFIEX_HW_STATUS_RESET &&
@@ -621,7 +623,7 @@ int mwifiex_send_cmd(struct mwifiex_private *priv, u16 cmd_no,
}
/* Initialize the command node */
- mwifiex_init_cmd_node(priv, cmd_node, cmd_oid, data_buf, sync);
+ mwifiex_init_cmd_node(priv, cmd_node, cmd_no, data_buf, sync);
if (!cmd_node->cmd_skb) {
mwifiex_dbg(adapter, ERROR,
@@ -822,9 +824,6 @@ int mwifiex_process_cmdresp(struct mwifiex_adapter *adapter)
uint16_t cmdresp_result;
unsigned long flags;
- /* Now we got response from FW, cancel the command timer */
- del_timer_sync(&adapter->cmd_timer);
-
if (!adapter->curr_cmd || !adapter->curr_cmd->resp_skb) {
resp = (struct host_cmd_ds_command *) adapter->upld_buf;
mwifiex_dbg(adapter, ERROR,
@@ -833,9 +832,20 @@ int mwifiex_process_cmdresp(struct mwifiex_adapter *adapter)
return -1;
}
+ resp = (struct host_cmd_ds_command *)adapter->curr_cmd->resp_skb->data;
+ orig_cmdresp_no = le16_to_cpu(resp->command);
+ cmdresp_no = (orig_cmdresp_no & HostCmd_CMD_ID_MASK);
+
+ if (adapter->curr_cmd->cmd_no != cmdresp_no) {
+ mwifiex_dbg(adapter, ERROR,
+ "cmdresp error: cmd=0x%x cmd_resp=0x%x\n",
+ adapter->curr_cmd->cmd_no, cmdresp_no);
+ return -1;
+ }
+ /* Now we got response from FW, cancel the command timer */
+ del_timer_sync(&adapter->cmd_timer);
clear_bit(MWIFIEX_IS_CMD_TIMEDOUT, &adapter->work_flags);
- resp = (struct host_cmd_ds_command *) adapter->curr_cmd->resp_skb->data;
if (adapter->curr_cmd->cmd_flag & CMD_F_HOSTCMD) {
/* Copy original response back to response buffer */
struct mwifiex_ds_misc_cmd *hostcmd;
@@ -849,7 +859,6 @@ int mwifiex_process_cmdresp(struct mwifiex_adapter *adapter)
memcpy(hostcmd->cmd, resp, size);
}
}
- orig_cmdresp_no = le16_to_cpu(resp->command);
/* Get BSS number and corresponding priv */
priv = mwifiex_get_priv_by_id(adapter,
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index b025ba1..3e442c7 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -747,7 +747,7 @@ struct mwifiex_bss_prio_tbl {
struct cmd_ctrl_node {
struct list_head list;
struct mwifiex_private *priv;
- u32 cmd_oid;
+ u32 cmd_no;
u32 cmd_flag;
struct sk_buff *cmd_skb;
struct sk_buff *resp_skb;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2 2/3] nl80211: Limit certain commands to interface owner
From: Denis Kenzior @ 2019-06-21 17:14 UTC (permalink / raw)
To: Arend Van Spriel, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <11852f40-67e5-9122-7d82-077bdd0b014a@broadcom.com>
Hi Arend,
On 06/21/2019 03:09 AM, Arend Van Spriel wrote:
> On 6/21/2019 12:07 AM, Denis Kenzior wrote:
>> If the wdev object has been created (via NEW_INTERFACE) with
>> SOCKET_OWNER attribute set, then limit certain commands only to the
>> process that created that wdev.
>>
>> This can be used to make sure no other process on the system interferes
>> by sending unwanted scans, action frames or any other funny business.
>
> The flag is a good addition opposed to having handlers deal with it.
> However, earlier motivation for SOCKET_OWNER use was about netlink
> multicast being unreliable, which I can agree to. However, avoiding
??? I can't agree to that as I have no idea what you're talking about
:) Explain? SOCKET_OWNER was introduced mainly to bring down links /
scans / whatever in case the initiating process died. As a side effect
it also helped in the beginning when users ran iwd + wpa_s
simultaneously (by accident) and all sorts of fun ensued. We then
re-used SOCKET_OWNER for running EAPoL over NL80211. But 'multicast
unreliability' was never an issue that I recall?
> "funny business" is a different thing. Our testing infrastructure is
> doing all kind of funny business. Guess we will need to refrain from
So you're going behind the managing daemon's back and messing with the
kernel state... I guess the question is why? But really, if wpa_s
wants to tolerate that, that is their problem :) iwd doesn't want to,
nor do we want to deal with the various race conditions and corner cases
associated with that. Life is hard as it is ;)
> using any user-space wireless tools that use the SOCKET_OWNER attribute,
> but how do we know? Somehow I suspect iwd is one to avoid ;-) I have yet
I guess you will be avoiding wpa_s since that one uses SOCKET_OWNER too ;)
> to give iwd a spin, but this SOCKET_OWNER strategy kept me from it.
> Maybe iwd could have a developer option which disables the use of the
> SOCKET_OWNER attribute.
Okay? Not sure what you're trying to say here? I'd interpret this as
"You guys suck. I'm taking my ball and going home?" but I hope this
isn't what you're saying?
Regards,
-Denis
^ permalink raw reply
* [PATCH] mt76: mt7615: remove cfg80211_chan_def from mt7615_set_channel signature
From: Lorenzo Bianconi @ 2019-06-21 17:15 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
Simplify mt7615_set_channel signature removing cfg80211_chan_def
parameter since it is not actually used
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index d21407ddda31..ea6b2315c6e5 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -130,8 +130,7 @@ static void mt7615_remove_interface(struct ieee80211_hw *hw,
mutex_unlock(&dev->mt76.mutex);
}
-static int mt7615_set_channel(struct mt7615_dev *dev,
- struct cfg80211_chan_def *def)
+static int mt7615_set_channel(struct mt7615_dev *dev)
{
int ret;
@@ -196,7 +195,7 @@ static int mt7615_config(struct ieee80211_hw *hw, u32 changed)
if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
ieee80211_stop_queues(hw);
- ret = mt7615_set_channel(dev, &hw->conf.chandef);
+ ret = mt7615_set_channel(dev);
ieee80211_wake_queues(hw);
}
--
2.21.0
^ 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