* [PATCH] nl80211: add iftype mask when sending iftype_data
From: John Crispin @ 2019-04-12 12:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin
Add the iftype mask to the blob passed to userland. This allows hostapd to
find the entry applicable for constructing the HE beacons of an AP.
Signed-off-by: John Crispin <john@phrozen.org>
---
include/uapi/linux/nl80211.h | 3 +++
net/wireless/nl80211.c | 4 +++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 84fa62bc2c7d..da6fb7624a11 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -3330,6 +3330,8 @@ enum nl80211_mpath_info {
* capabilities IE
* @NL80211_BAND_IFTYPE_ATTR_HE_CAP_PPE: HE PPE thresholds information as
* defined in HE capabilities IE
+ * @NL80211_BAND_IFTYPE_ATTR_TYPE_MASK: The IFTYPEs that this element is
+ * applicable for
* @NL80211_BAND_IFTYPE_ATTR_MAX: highest band HE capability attribute currently
* defined
* @__NL80211_BAND_IFTYPE_ATTR_AFTER_LAST: internal use
@@ -3342,6 +3344,7 @@ enum nl80211_band_iftype_attr {
NL80211_BAND_IFTYPE_ATTR_HE_CAP_PHY,
NL80211_BAND_IFTYPE_ATTR_HE_CAP_MCS_SET,
NL80211_BAND_IFTYPE_ATTR_HE_CAP_PPE,
+ NL80211_BAND_IFTYPE_ATTR_TYPE_MASK,
/* keep last */
__NL80211_BAND_IFTYPE_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 25a9e3b5c154..87d1127e8cc1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1421,7 +1421,9 @@ nl80211_send_iftype_data(struct sk_buff *msg,
sizeof(he_cap->he_mcs_nss_supp),
&he_cap->he_mcs_nss_supp) ||
nla_put(msg, NL80211_BAND_IFTYPE_ATTR_HE_CAP_PPE,
- sizeof(he_cap->ppe_thres), he_cap->ppe_thres))
+ sizeof(he_cap->ppe_thres), he_cap->ppe_thres) ||
+ nla_put_u16(msg, NL80211_BAND_IFTYPE_ATTR_TYPE_MASK,
+ iftdata->types_mask))
return -ENOBUFS;
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 1/6] ath10k: use clean packet headers
From: Kalle Valo @ 2019-04-12 12:54 UTC (permalink / raw)
To: Erik Stromdahl; +Cc: linux-wireless, ath10k, Alagu Sankar
In-Reply-To: <20190409190851.4557-2-erik.stromdahl@gmail.com>
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> From: Alagu Sankar <alagusankar@silex-india.com>
>
> HTC header carries junk values that may be interpreted by the firmware
> differently. Enable credit update only if flow control is enabled for
> the corresponding endpoint.
>
> PLL clock setting sequence does not mask the PLL_CONTROL
> register value. Side effect of not masking the values is not known as
> the entire pll clock setting sequence is undocumented.
One logical change per patch, please. So this should be split to two.
> Signed-off-by: Alagu Sankar <alagusankar@silex-india.com>
Erik's s-o-b missing.
> --- a/drivers/net/wireless/ath/ath10k/hw.c
> +++ b/drivers/net/wireless/ath/ath10k/hw.c
> @@ -814,6 +814,8 @@ static int ath10k_hw_qca6174_enable_pll_clock(struct ath10k *ar)
> if (ret)
> return -EINVAL;
>
> + reg_val &= ~(WLAN_PLL_CONTROL_REFDIV_MASK | WLAN_PLL_CONTROL_DIV_MASK |
> + WLAN_PLL_CONTROL_NOPWD_MASK);
> reg_val |= (SM(hw_clk->refdiv, WLAN_PLL_CONTROL_REFDIV) |
> SM(hw_clk->div, WLAN_PLL_CONTROL_DIV) |
> SM(1, WLAN_PLL_CONTROL_NOPWD));
The commit log mentions that there are no visible changes after this
patch. So why add it? :)
And do note that this also changes functionality for QCA6174 and QCA9377
PCI devices, so we have to be careful here.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 0/6] ath10k: SDIO and high latency patches from Silex
From: Kalle Valo @ 2019-04-12 12:36 UTC (permalink / raw)
To: Erik Stromdahl; +Cc: linux-wireless, ath10k
In-Reply-To: <20190409190851.4557-1-erik.stromdahl@gmail.com>
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> This series adds a few more fixes for SDIO and high latency devices.
>
> I have had these on my private tree for quite some time now so they
> should be considered fairly well tested.
>
> 4 out of 6 patches are from Alagu Sankar at Silex.
> I have made some adjustments to some of them in order to make them
> smaller and easier to review.
>
> Alagu Sankar (4):
> ath10k: use clean packet headers
> ath10k: high latency fixes for beacon buffer
> ath10k: sdio: read RX packets in bundles
> ath10k: sdio: add MSDU ID allocation in HTT TX path
>
> Erik Stromdahl (2):
> ath10k: sdio: add missing error check
> ath10k: sdio: replace skb_trim with explicit set of skb->len
Bad timing as also me and Wen have been cleaning up these patches and
finalising the SDIO support so our work overlapped. I'll send our
version of patches soon and we can then compare.
--
Kalle Valo
^ permalink raw reply
* [PATCH] mt76: usb: fix possible memory leak during suspend/resume
From: Lorenzo Bianconi @ 2019-04-12 12:27 UTC (permalink / raw)
To: nbd; +Cc: linux-wireless, lorenzo.bianconi, sgruszka
In-Reply-To: <cover.1555071870.git.lorenzo@kernel.org>
Disable mt76u_tx_tasklet at the end of mt76u_stop_queues in order to
properly deallocate all pending skbs during suspend/resume phase
Fixes: b40b15e1521f ("mt76: add usb support to mt76 layer")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index a3acc070063a..575207133775 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -842,10 +842,10 @@ static void mt76u_stop_tx(struct mt76_dev *dev)
void mt76u_stop_queues(struct mt76_dev *dev)
{
tasklet_disable(&dev->usb.rx_tasklet);
- tasklet_disable(&dev->usb.tx_tasklet);
-
mt76u_stop_rx(dev);
+
mt76u_stop_tx(dev);
+ tasklet_disable(&dev->usb.tx_tasklet);
}
EXPORT_SYMBOL_GPL(mt76u_stop_queues);
--
2.20.1
^ permalink raw reply related
* Re: gsmtap design/extensions?
From: Johannes Berg @ 2019-04-12 12:24 UTC (permalink / raw)
To: Harald Welte
Cc: openbsc, radiotap, linux-wireless, Subash Abhinov Kasiviswanathan,
Dan Williams, Bjørn Mork, netdev, Sean Tranchetti,
Aleksander Morgado
In-Reply-To: <20190410233213.GN25552@nataraja>
On Thu, 2019-04-11 at 01:32 +0200, Harald Welte wrote:
> Hi Johannes,
>
> On Tue, Apr 09, 2019 at 03:50:45PM +0200, Johannes Berg wrote:
> > As I'm looking into adding a generic cell modem framework to the linux
> > kernel (to create session netdevs etc.), I started looking for a
> > metadata encapsulation, a la Radiotap (I'm a wifi guy :-) ).
>
> Is there any discussion about "session netdevs, etc." anywhere? What exactly
> do you have in mind for that "generic cell modem framework"? I'm quite
> curious to learn more about it and happy to provide feedback from the
> perspective of my cellular protocols/specs/systems knowledge.
Yeah. I was too much in my little bubble when I wrote this. I just wrote
a lengthy reply to Marcel that explains a little more, but basically to
summarize:
Kernel drivers need to transport multiple data streams, like VoLTE (IP)
data, IP data, and control data. Currently, they do this in various ways
(cdc_mbim uses VLAN tags, rmnet/qmi_wwan uses Qualcomm QMI headers),
when you capture data you have to understand what you're dealing with
and maybe extend wireshark to even understand these headers.
I'm looking for a general vendor-agnostic encapsulation that would solve
this part of the problem.
At the same time, I come from WiFi, where - while we don't have these
sessions as such but can have different virtual interfaces as well, e.g.
for connections to different APs - it's often very useful to also
understand the PHY parameters that were used for TX/seen on RX. Now, I
realize this isn't something that modems will do right now - they just
don't seem to tell you any lower-level information on RX of a packet,
but it seemed like it might be worthwhile to not *exclude* this
possibility either.
> > 1) Why the design with encapsulating it in UDP? Radiotap is just a raw
> > header without IP etc. in front, and you use it with tcpdump,
> > wireshark or similar tools on the local system. What's the value in
> > having something "network transparent"?
>
> GSMTAP was designed as a format to encapsulate protocols normally not spoken over IP
> (such as classic GSM radio protocols, e.g. the Layer 2 LAPDm over GSM Um)
> inside an IP transport.
Sure, but wifi is also not spoken over IP, yet we don't encapsulate our
802.11 frames into IP to show them in wireshark :-)
> The existing implementations of such protocols all live outside of the
> kernel but in userspace. So you either have
>
> a) a pure SDR software implementation of a GSM phy, whether on the MS/UE
> side or on the BTS/network side, or whether in sniffing mode, running
> as a userspace process. This could e.g. be airprobe or gr-gsm
>
> b) a OsmocomBB phone attached over serial port running the Osmocom Layer1
> firmware on the baseband processor, with some userspace program on a Linux
> PC implementing higher layers
>
> c) GSM base station software such as osmo-bts, running in userspace
>
> d) Using an old nokia phone attached via serial cable to a Linux PC running
> dct3-gsmtap.
Sure.
> So for any of those, if you want to provide real-time data streams, you have to
> somehow transmit those over some kind of network technology. One could have
> done raw ethernet frames or raw IP frames, but using UDP seemed straight-forward
> as one can create UDP socket from non-privileged processes.
This is the part I guess I don't understand. I haven't really tried, but
it seems you should be able to encapsulate arbitrary protocols into
802.3 OUI-based ethertype or so?
But I guess if your primary use case is actually to transport them over
the network, this makes more sense.
Our primary use case with wifi is much more local - capture what's going
on - but do the capturing on the local system and write it to a file
there.
> We also have a virtual physical layer between OsmocomBB and OsmoBTS called
> virt_phy where the GSMTAP over multicast IP is used to simulate/virtualize
> the entire Layer1 / PHY / radio interface between phone and base station.
>
> Once again, all related network elements are implemented in userspace,
> and having an
...?
> > (speaking of versions - the docs say "version, set to 0x01 currently"
> > but "#define GSMTAP_VERSION 0x02")
>
> Sorry, it's the usual "developer changes code but not comment". patches
> are welcome, we use gerrit.osmocom.org :)
Ok :-)
> > 3) Does the packet data follow the gsmtap header? It's not really clear
> > to me based on reading the wireshark code.
>
> Sure, the packet data follows the GSMTAP header, and the type of data
> is defined by the GSMTAP type / sub-type as per the specific use case. As
> you can see, there's 18 TYPE by now (each of which has at least one
> program/implementation generating the data).
Right.
> I think the best way to learn about GSMTAP is to use any of the many
> programs that support it by now. I think not only the examples above
> use it, but meanwhile many others like the independently-developed OpenBTS
> project that's unrelated to Osmocom, as are other projects implementing LTE.
OK.
> > In particular, the data I'm thinking of is higher-level things, like the
> > session ID for a frame when it's going through the kernel, or perhaps a
> > flow label on RX, etc.
>
> I'm not quite sure how that relates to GSM? GSMTAP so far was intended
> to encapsulate ETSI/3GPP messages inside UDP/IP, particularly messages of
> protocols that don't traditionally are transported over IP baesd transports.
Yeah, I think here's where I got confused or just don't know enough
about GSM.
Basically, I was looking at it as if it was like WiFi in a sense - you
have an IP frame, you're going to transport it over some physical link,
so it gets PHY information in the sense of modulation etc.
That doesn't seem to be the case for GSM, I guess? Does the IP frame get
encapsulated in some kind of 3GPP message first, and then transported
over the physical link, and the physical link info isn't even there in
GSMTAP?
> Having said, we're open to extending the scope - it just all needs to make
> sense
See above for a bit better description of what I'm trying to solve.
> > I do note that this
> > wouldn't be compatible with the current wireshark code as it doesn't
> > check the version, just shows it...
>
> If that's the case that's sad, and I should have paid more attention to
> it when originally writing it. We should get a related fix into
> wireshark ASAP then. But then, the current dissector would just state
> something like unsupported version instead of showing some garbage it
> cannot parse. Either way, you will of course need new sources and
> sink side implemetations.
Sure. Just a note in passing.
> > Or would it make more sense to define a new ARPHDR_WWANTAP like
> > ARPHDR_IEEE80211_RADIOTAP and just use that instead of encapsulating in
> > IP/UDP, and then have a completely new (extensible) protocol inside of
> > that?
>
> No userspace source would ever be able to generate such data and stream
> it real-time into wireshark, would it? Sure, I can write pcap file with
> such ARPHDR_* values, but I could never do this in real-time. For many
> but not all use cases, that's really what it is: A vehicle to stream
> real-time non-IP protocol traces into wireshark so it can visualize
> the protocol traces.
I think you can pipe a stream into wireshark?
To me it feels like the wrong thing to actually make wireshark listen on
"lo" or "eth0" or something to get data from the cellular that's
(locally) generated by another application, but I guess that's only
about how you think about it - and if it's not generated locally then
that's an easy transport. I'm not sure it makes *sense* because then you
need permissions to capture on the wired network etc. where you don't
*really* need that for this stream, but it's convenient for sure.
johannes
^ permalink raw reply
* Re: gsmtap design/extensions?
From: Johannes Berg @ 2019-04-12 12:12 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Vadim Yanitskiy, Harald Welte, OpenBSC Mailing List,
Sean Tranchetti, radiotap, Dan Williams, netdev,
open list:NFC SUBSYSTEM, Aleksander Morgado,
Subash Abhinov Kasiviswanathan, Bjørn Mork
In-Reply-To: <6F1998DC-EFD2-4145-BD81-A80F9DC7ED2D@holtmann.org>
Hi Marcel,
> before you go all out and define this, it would suggest to understand
> what meta-data for the connection contexts you actually need as well.
> The data path itself is just a pipe and has not all the information
> attached with it. That goes via the control path and that is normally
> in user space and carries the real important information to make
> useful analysis of how the data path / context is setup.
Yes, that's true, though the control path is actually going through one
of the data pipes as well.
> From what I am seeing right now is that unless you have a method to
> also feed the control path into your GSMTAPv3, then this is rather
> useless.
So the control path *itself* would be there, I guess, but ...
> The majority of the debugging is really done for the control path. For
> oFono that is OFONO_DEBUG=1 environment variable and while it works it
> is not the most elegant solution. I would love to feed that into a
> generic debugging / tap that you can read out later.
there's definitely room for more information than _just_ the control
path "chat", also application state etc. would be useful, and logging
etc.
Typically on wifi we feed all of this together into kernel tracing (to
record with trace-cmd) rather than trying to encapsulate it some other
way.
> As a side note, for Bluetooth we created a path where the bluetoothd
> can feed back its control debugging data back into the Bluetooth
> monitor in the kernel to allow combined userspace, mgmt and HCI
> tracing. Some really nasty issues could only be triaged by having all
> the meta data with a common timestamp.
Right. This is something we'd typically use tracing for in wifi.
I don't really know what the right model for WWAN would be, I guess.
Right now - and I really should've said this before - really the only
problem I was thinking of was how we can mux multiple "chat" sessions
with a device into a single data stream.
Currently, this is all vendor-specific. If you have a Qualcomm modem,
you'd be able to see all the open sessions on the underlying netdev, and
the QMI header tells you what session a given 'packet' belongs to, and
if you follow along maybe you can figure out if this is a control or IP
'packet' (could be an AT command).
cdc_mbim uses VLAN tags instead to achieve this, and decapsulates the
VLAN tags to send them down to the hardware in a different way.
There are a few reasons why I think that this model of having a single
underlying netdev controlled by the modem driver, with additional
netdevs layered on top in software will not work right in the future. I
think drivers should and will need to migrate to creating "real" netdevs
for the sessions instead of pure software ones.
But if you do this, you lose the ability to listen to all the session
streams at the same time, you can only do it for each netdev. Adding
this ability back seems worthwhile, but then we probably shouldn't do it
in a vendor-specific way, but rather in a generic way.
So basically right now that's all I'm trying to solve. In WiFi we don't
have the problem of "sessions" because we just use the addresses in the
frames to disambiguate - on such 'monitor' netdevs we see the frames
including full 802.11 headers.
Now, here's maybe where I'm getting off the right path - in wifi we
mostly couple that with PHY information as well, and so we have PHY
information + full 802.11 headers + data for capturing what's going on.
I figured that theoretically at least that would be possible/useful for
the modem as well (obviously control packets have no PHY data), but
there doesn't seem to be any hardware that would actually expose data in
this way. Everyone I've spoken to says these things are only available
as modem trace data. What I haven't figured out though is if that's by
some other design trade-off, or just because no such infrastructure
is/was available.
It may well be that doing kernel-tracing instead of doing it via some
kind of monitor netdev is perfectly sufficient, but I have a feeling
that the relative simplicity of starting tcpdump/wireshark might be
preferable.
johannes
^ permalink raw reply
* Re: [PATCH 5.1] mt76x02: avoid status_list.lock and sta->rate_ctrl_lock dependency
From: Felix Fietkau @ 2019-04-12 12:11 UTC (permalink / raw)
To: Stanislaw Gruszka, linux-wireless; +Cc: Lorenzo Bianconi, Kalle Valo
In-Reply-To: <20190405114256.6416-1-sgruszka@redhat.com>
On 2019-04-05 13:42, Stanislaw Gruszka wrote:
> Move ieee80211_tx_status_ext() outside of status_list lock section
> in order to avoid locking dependency and possible deadlock reposed by
> LOCKDEP in below warning.
>
> Also do mt76_tx_status_lock() just before it's needed.
>
> [ 440.224832] WARNING: possible circular locking dependency detected
> [ 440.224833] 5.1.0-rc2+ #22 Not tainted
> [ 440.224834] ------------------------------------------------------
> [ 440.224835] kworker/u16:28/2362 is trying to acquire lock:
> [ 440.224836] 0000000089b8cacf (&(&q->lock)->rlock#2){+.-.}, at: mt76_wake_tx_queue+0x4c/0xb0 [mt76]
> [ 440.224842]
> but task is already holding lock:
> [ 440.224842] 000000002cfedc59 (&(&sta->lock)->rlock){+.-.}, at: ieee80211_stop_tx_ba_cb+0x32/0x1f0 [mac80211]
> [ 440.224863]
> which lock already depends on the new lock.
>
> [ 440.224863]
> the existing dependency chain (in reverse order) is:
> [ 440.224864]
> -> #3 (&(&sta->lock)->rlock){+.-.}:
> [ 440.224869] _raw_spin_lock_bh+0x34/0x40
> [ 440.224880] ieee80211_start_tx_ba_session+0xe4/0x3d0 [mac80211]
> [ 440.224894] minstrel_ht_get_rate+0x45c/0x510 [mac80211]
> [ 440.224906] rate_control_get_rate+0xc1/0x140 [mac80211]
> [ 440.224918] ieee80211_tx_h_rate_ctrl+0x195/0x3c0 [mac80211]
> [ 440.224930] ieee80211_xmit_fast+0x26d/0xa50 [mac80211]
> [ 440.224942] __ieee80211_subif_start_xmit+0xfc/0x310 [mac80211]
> [ 440.224954] ieee80211_subif_start_xmit+0x38/0x390 [mac80211]
> [ 440.224956] dev_hard_start_xmit+0xb8/0x300
> [ 440.224957] __dev_queue_xmit+0x7d4/0xbb0
> [ 440.224968] ip6_finish_output2+0x246/0x860 [ipv6]
> [ 440.224978] mld_sendpack+0x1bd/0x360 [ipv6]
> [ 440.224987] mld_ifc_timer_expire+0x1a4/0x2f0 [ipv6]
> [ 440.224989] call_timer_fn+0x89/0x2a0
> [ 440.224990] run_timer_softirq+0x1bd/0x4d0
> [ 440.224992] __do_softirq+0xdb/0x47c
> [ 440.224994] irq_exit+0xfa/0x100
> [ 440.224996] smp_apic_timer_interrupt+0x9a/0x220
> [ 440.224997] apic_timer_interrupt+0xf/0x20
> [ 440.224999] cpuidle_enter_state+0xc1/0x470
> [ 440.225000] do_idle+0x21a/0x260
> [ 440.225001] cpu_startup_entry+0x19/0x20
> [ 440.225004] start_secondary+0x135/0x170
> [ 440.225006] secondary_startup_64+0xa4/0xb0
> [ 440.225007]
> -> #2 (&(&sta->rate_ctrl_lock)->rlock){+.-.}:
> [ 440.225009] _raw_spin_lock_bh+0x34/0x40
> [ 440.225022] rate_control_tx_status+0x4f/0xb0 [mac80211]
> [ 440.225031] ieee80211_tx_status_ext+0x142/0x1a0 [mac80211]
> [ 440.225035] mt76x02_send_tx_status+0x2e4/0x340 [mt76x02_lib]
> [ 440.225037] mt76x02_tx_status_data+0x31/0x40 [mt76x02_lib]
> [ 440.225040] mt76u_tx_status_data+0x51/0xa0 [mt76_usb]
> [ 440.225042] process_one_work+0x237/0x5d0
> [ 440.225043] worker_thread+0x3c/0x390
> [ 440.225045] kthread+0x11d/0x140
> [ 440.225046] ret_from_fork+0x3a/0x50
> [ 440.225047]
> -> #1 (&(&list->lock)->rlock#8){+.-.}:
> [ 440.225049] _raw_spin_lock_bh+0x34/0x40
> [ 440.225052] mt76_tx_status_skb_add+0x51/0x100 [mt76]
> [ 440.225054] mt76x02u_tx_prepare_skb+0xbd/0x116 [mt76x02_usb]
> [ 440.225056] mt76u_tx_queue_skb+0x5f/0x180 [mt76_usb]
> [ 440.225058] mt76_tx+0x93/0x190 [mt76]
> [ 440.225070] ieee80211_tx_frags+0x148/0x210 [mac80211]
> [ 440.225081] __ieee80211_tx+0x75/0x1b0 [mac80211]
> [ 440.225092] ieee80211_tx+0xde/0x110 [mac80211]
> [ 440.225105] __ieee80211_tx_skb_tid_band+0x72/0x90 [mac80211]
> [ 440.225122] ieee80211_send_auth+0x1f3/0x360 [mac80211]
> [ 440.225141] ieee80211_auth.cold.40+0x6c/0x100 [mac80211]
> [ 440.225156] ieee80211_mgd_auth.cold.50+0x132/0x15f [mac80211]
> [ 440.225171] cfg80211_mlme_auth+0x149/0x360 [cfg80211]
> [ 440.225181] nl80211_authenticate+0x273/0x2e0 [cfg80211]
> [ 440.225183] genl_family_rcv_msg+0x196/0x3a0
> [ 440.225184] genl_rcv_msg+0x47/0x8e
> [ 440.225185] netlink_rcv_skb+0x3a/0xf0
> [ 440.225187] genl_rcv+0x24/0x40
> [ 440.225188] netlink_unicast+0x16d/0x210
> [ 440.225189] netlink_sendmsg+0x204/0x3b0
> [ 440.225191] sock_sendmsg+0x36/0x40
> [ 440.225193] ___sys_sendmsg+0x259/0x2b0
> [ 440.225194] __sys_sendmsg+0x47/0x80
> [ 440.225196] do_syscall_64+0x60/0x1f0
> [ 440.225197] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 440.225198]
> -> #0 (&(&q->lock)->rlock#2){+.-.}:
> [ 440.225200] lock_acquire+0xb9/0x1a0
> [ 440.225202] _raw_spin_lock_bh+0x34/0x40
> [ 440.225204] mt76_wake_tx_queue+0x4c/0xb0 [mt76]
> [ 440.225215] ieee80211_agg_start_txq+0xe8/0x2b0 [mac80211]
> [ 440.225225] ieee80211_stop_tx_ba_cb+0xb8/0x1f0 [mac80211]
> [ 440.225235] ieee80211_ba_session_work+0x1c1/0x2f0 [mac80211]
> [ 440.225236] process_one_work+0x237/0x5d0
> [ 440.225237] worker_thread+0x3c/0x390
> [ 440.225239] kthread+0x11d/0x140
> [ 440.225240] ret_from_fork+0x3a/0x50
> [ 440.225240]
> other info that might help us debug this:
>
> [ 440.225241] Chain exists of:
> &(&q->lock)->rlock#2 --> &(&sta->rate_ctrl_lock)->rlock --> &(&sta->lock)->rlock
>
> [ 440.225243] Possible unsafe locking scenario:
>
> [ 440.225244] CPU0 CPU1
> [ 440.225244] ---- ----
> [ 440.225245] lock(&(&sta->lock)->rlock);
> [ 440.225245] lock(&(&sta->rate_ctrl_lock)->rlock);
> [ 440.225246] lock(&(&sta->lock)->rlock);
> [ 440.225247] lock(&(&q->lock)->rlock#2);
> [ 440.225248]
> *** DEADLOCK ***
>
> [ 440.225249] 5 locks held by kworker/u16:28/2362:
> [ 440.225250] #0: 0000000048fcd291 ((wq_completion)phy0){+.+.}, at: process_one_work+0x1b5/0x5d0
> [ 440.225252] #1: 00000000f1c6828f ((work_completion)(&sta->ampdu_mlme.work)){+.+.}, at: process_one_work+0x1b5/0x5d0
> [ 440.225254] #2: 00000000433d2b2c (&sta->ampdu_mlme.mtx){+.+.}, at: ieee80211_ba_session_work+0x5c/0x2f0 [mac80211]
> [ 440.225265] #3: 000000002cfedc59 (&(&sta->lock)->rlock){+.-.}, at: ieee80211_stop_tx_ba_cb+0x32/0x1f0 [mac80211]
> [ 440.225276] #4: 000000009d7b9a44 (rcu_read_lock){....}, at: ieee80211_agg_start_txq+0x33/0x2b0 [mac80211]
> [ 440.225286]
> stack backtrace:
> [ 440.225288] CPU: 2 PID: 2362 Comm: kworker/u16:28 Not tainted 5.1.0-rc2+ #22
> [ 440.225289] Hardware name: LENOVO 20KGS23S0P/20KGS23S0P, BIOS N23ET55W (1.30 ) 08/31/2018
> [ 440.225300] Workqueue: phy0 ieee80211_ba_session_work [mac80211]
> [ 440.225301] Call Trace:
> [ 440.225304] dump_stack+0x85/0xc0
> [ 440.225306] print_circular_bug.isra.38.cold.58+0x15c/0x195
> [ 440.225307] check_prev_add.constprop.48+0x5f0/0xc00
> [ 440.225309] ? check_prev_add.constprop.48+0x39d/0xc00
> [ 440.225311] ? __lock_acquire+0x41d/0x1100
> [ 440.225312] __lock_acquire+0xd98/0x1100
> [ 440.225313] ? __lock_acquire+0x41d/0x1100
> [ 440.225315] lock_acquire+0xb9/0x1a0
> [ 440.225317] ? mt76_wake_tx_queue+0x4c/0xb0 [mt76]
> [ 440.225319] _raw_spin_lock_bh+0x34/0x40
> [ 440.225321] ? mt76_wake_tx_queue+0x4c/0xb0 [mt76]
> [ 440.225323] mt76_wake_tx_queue+0x4c/0xb0 [mt76]
> [ 440.225334] ieee80211_agg_start_txq+0xe8/0x2b0 [mac80211]
> [ 440.225344] ieee80211_stop_tx_ba_cb+0xb8/0x1f0 [mac80211]
> [ 440.225354] ieee80211_ba_session_work+0x1c1/0x2f0 [mac80211]
> [ 440.225356] process_one_work+0x237/0x5d0
> [ 440.225358] worker_thread+0x3c/0x390
> [ 440.225359] ? wq_calc_node_cpumask+0x70/0x70
> [ 440.225360] kthread+0x11d/0x140
> [ 440.225362] ? kthread_create_on_node+0x40/0x40
> [ 440.225363] ret_from_fork+0x3a/0x50
>
> Cc: stable@vger.kernel.org
> Fixes: 88046b2c9f6d ("mt76: add support for reporting tx status with skb")
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Felix Fietkau <nbd@nbd.name>
- Felix
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v3 00/11] Add support for Orange Pi 3
From: Ondřej Jirman @ 2019-04-12 12:10 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Rutland, Maxime Ripard, Chi-Hsien Lin, dri-devel,
linux-sunxi, linux-stm32, brcm80211-dev-list, David Airlie,
Jose Abreu, Naveen Gupta, Linus Walleij, devicetree,
Arend van Spriel, Alexandre Torgue, Hante Meuleman,
open list:GPIO SUBSYSTEM, Rob Herring, Wright Feng,
Giuseppe Cavallaro, linux-arm-kernel, Franky Lin, Maxime Coquelin,
brcm80211-dev-list.pdl, netdev, linux-wireless, linux-kernel,
Kalle Valo, Daniel Vetter, David S. Miller
In-Reply-To: <CAGb2v64HgPePM=rk_kSdS7yFx4S4TR=tpGC2yQ6ruDCvBnosiA@mail.gmail.com>
Hello ChenYu,
On Fri, Apr 12, 2019 at 07:05:05PM +0800, Chen-Yu Tsai wrote:
> On Thu, Apr 11, 2019 at 6:19 PM megous via linux-sunxi
> <linux-sunxi@googlegroups.com> wrote:
> >
> > From: Ondrej Jirman <megous@megous.com>
> >
> > This series implements support for Xunlong Orange Pi 3 board.
> >
> > Unfortunately, this board needs some small driver patches, so I have
> > split the boards DT patch into chunks that require patches for drivers
> > in various subsystems.
> >
> > Suggested merging plan/dependencies:
> >
> > - Pinctrl and stmmac patches are needed for ethernet support.
> > (patches 1-5)
> > - HDMI support was changed, please review. (patches 6-8)
> > - brcmfmac patch 9, fixing firmware file selection, can be merged
> > now, after review, as it doesn't depend on anything (please
> > review :))
> > - mmc1 pinconf (patch 10) can probably be merged now, too (it will
> > certainly be used soon by all the other WiFi featuring boards
> > based on H6)
> > - WiFi dts patch will have to wait for H6 RTC patches, which in turn
> > depend on ChenYu's RTC series, to be merged. That will take a
> > while yet. I'm just keeping it in the series for completness.
> > (patch 11)
>
> Unfortunately I will not have time to tackle this for the next release.
> Furthermore, I'd like to do this after the new clk parenting stuff lands.
> Otherwise it's going to be a mess, as the clock tree is a bit convoluted
> compared to previous SoCs.
I've sent out a patch series that addresses part of that for now.
So perhaps we can start with that and incrementally get to a full support,
of H6's complexities around clocks managed by RTC.
thanks,
o.
> ChenYu
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mt76: introduce mt76_free_device routine
From: Felix Fietkau @ 2019-04-12 12:07 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, lorenzo.bianconi, sgruszka
In-Reply-To: <aec149cae6ae7d83815aee349804ce32bc74192b.1553682658.git.lorenzo@kernel.org>
On 2019-03-27 12:41, Lorenzo Bianconi wrote:
> Move mt76_tx_free in mt76_free_device routine in order to
> unmap all txwi descriptors at module unload
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Applied, thanks.
- Felix
^ permalink raw reply
* WARNING in zd_mac_clear
From: syzbot @ 2019-04-12 11:46 UTC (permalink / raw)
To: andreyknvl, davem, dsd, kune, kvalo, linux-kernel, linux-usb,
linux-wireless, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 9a33b369 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan/tree/usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=101a06dd200000
kernel config: https://syzkaller.appspot.com/x/.config?x=23e37f59d94ddd15
dashboard link: https://syzkaller.appspot.com/bug?extid=74c65761783d66a9c97c
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1170c22d200000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1496adbb200000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+74c65761783d66a9c97c@syzkaller.appspotmail.com
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
usb 1-1: reset low-speed USB device number 2 using dummy_hcd
usb 1-1: read over firmware interface failed: -71
usb 1-1: reset low-speed USB device number 2 using dummy_hcd
WARNING: CPU: 1 PID: 21 at drivers/net/wireless/zydas/zd1211rw/zd_mac.c:238
zd_mac_clear+0xb0/0xe0 drivers/net/wireless/zydas/zd1211rw/zd_mac.c:238
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 21 Comm: kworker/1:1 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xe8/0x16e lib/dump_stack.c:113
panic+0x29d/0x5f2 kernel/panic.c:214
__warn.cold+0x20/0x48 kernel/panic.c:571
report_bug+0x262/0x2a0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:179 [inline]
fixup_bug arch/x86/kernel/traps.c:174 [inline]
do_error_trap+0x130/0x1f0 arch/x86/kernel/traps.c:272
do_invalid_op+0x37/0x40 arch/x86/kernel/traps.c:291
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
RIP: 0010:zd_mac_clear+0xb0/0xe0
drivers/net/wireless/zydas/zd1211rw/zd_mac.c:238
Code: e8 85 d0 60 f8 48 8d bb f8 2b 00 00 be ff ff ff ff e8 54 5a 46 f8 31
ff 89 c3 89 c6 e8 d9 d1 60 f8 85 db 75 d4 e8 60 d0 60 f8 <0f> 0b 5b 5d e9
57 d0 60 f8 48 c7 c7 58 05 cb 93 e8 fb e0 97 f8 eb
RSP: 0018:ffff8880a85c7310 EFLAGS: 00010293
RAX: ffff8880a84de200 RBX: 0000000000000000 RCX: ffffffff8910f507
RDX: 0000000000000000 RSI: ffffffff8910f510 RDI: 0000000000000005
RBP: 0000000000000001 R08: ffff8880a84de200 R09: ffffed1012f83a0b
R10: ffffed1012f83a0a R11: ffff888097c1d057 R12: 00000000ffffffb9
R13: ffff888097c18b20 R14: ffff888099456630 R15: ffffffff8f979398
probe+0x259/0x590 drivers/net/wireless/zydas/zd1211rw/zd_usb.c:1421
usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
really_probe+0x2da/0xb10 drivers/base/dd.c:509
driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
__device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
__device_attach+0x223/0x3a0 drivers/base/dd.c:844
bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
device_add+0xad2/0x16e0 drivers/base/core.c:2106
usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
really_probe+0x2da/0xb10 drivers/base/dd.c:509
driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
__device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
__device_attach+0x223/0x3a0 drivers/base/dd.c:844
bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
device_add+0xad2/0x16e0 drivers/base/core.c:2106
usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
hub_port_connect drivers/usb/core/hub.c:5089 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
port_event drivers/usb/core/hub.c:5350 [inline]
hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
kthread+0x313/0x420 kernel/kthread.c:253
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* INFO: trying to register non-static key in rtl_c2hcmd_launcher
From: syzbot @ 2019-04-12 11:46 UTC (permalink / raw)
To: andreyknvl, davem, kvalo, linux-kernel, linux-usb, linux-wireless,
netdev, pkshih, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 9a33b369 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan/tree/usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=14d4c1af200000
kernel config: https://syzkaller.appspot.com/x/.config?x=23e37f59d94ddd15
dashboard link: https://syzkaller.appspot.com/bug?extid=1fcc5ef45175fc774231
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15b6f0f3200000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=140c7c2d200000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1fcc5ef45175fc774231@syzkaller.appspotmail.com
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
rtl_usb: reg 0xf0, usbctrl_vendorreq TimeOut! status:0xffffffb9 value=0x0
rtl8192cu: Chip version 0x10
rtl_usb: reg 0xa, usbctrl_vendorreq TimeOut! status:0xffffffb9 value=0x0
rtl_usb: Too few input end points found
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xe8/0x16e lib/dump_stack.c:113
assign_lock_key kernel/locking/lockdep.c:786 [inline]
register_lock_class+0x11b8/0x1250 kernel/locking/lockdep.c:1095
__lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
lock_acquire+0x10d/0x2f0 kernel/locking/lockdep.c:4211
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x44/0x60 kernel/locking/spinlock.c:152
rtl_c2hcmd_launcher+0xd1/0x390
drivers/net/wireless/realtek/rtlwifi/base.c:2344
rtl_deinit_core+0x25/0x2d0 drivers/net/wireless/realtek/rtlwifi/base.c:574
rtl_usb_probe.cold+0x861/0xa70
drivers/net/wireless/realtek/rtlwifi/usb.c:1093
usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
really_probe+0x2da/0xb10 drivers/base/dd.c:509
driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
__device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
__device_attach+0x223/0x3a0 drivers/base/dd.c:844
bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
device_add+0xad2/0x16e0 drivers/base/core.c:2106
usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
really_probe+0x2da/0xb10 drivers/base/dd.c:509
driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
__device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
__device_attach+0x223/0x3a0 drivers/base/dd.c:844
bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
device_add+0xad2/0x16e0 drivers/base/core.c:2106
usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
hub_port_connect drivers/usb/core/hub.c:5089 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
port_event drivers/usb/core/hub.c:5350 [inline]
hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
kthread+0x313/0x420 kernel/kthread.c:253
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN PTI
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:rtl_free_entries_from_scan_list
drivers/net/wireless/realtek/rtlwifi/base.c:1933 [inline]
RIP: 0010:rtl_deinit_core+0x84/0x2d0
drivers/net/wireless/realtek/rtlwifi/base.c:575
Code: 4c 89 f2 48 c1 ea 03 80 3c 02 00 0f 85 52 02 00 00 4d 8b bc 24 c8 c4
00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 22 02 00 00 4d 39 f7 4d 8b 2f 4c 89 ff 0f 84 3d
RSP: 0018:ffff8880a84b7278 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: 0000000000000001 RCX: 1ffffffff27960ab
RDX: 0000000000000000 RSI: ffffffff88da7445 RDI: ffff888093c00b68
RBP: ffff888093c00b20 R08: ffff8880a8498000 R09: ffffed101278051d
R10: ffffed101278051c R11: ffff888093c028e3 R12: ffff888093c02540
R13: ffff88821add7848 R14: ffff888093c0ea08 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8880ad000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd01db19000 CR3: 000000009c01a000 CR4: 00000000001406f0
Call Trace:
rtl_usb_probe.cold+0x861/0xa70
drivers/net/wireless/realtek/rtlwifi/usb.c:1093
usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
really_probe+0x2da/0xb10 drivers/base/dd.c:509
driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
__device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
__device_attach+0x223/0x3a0 drivers/base/dd.c:844
bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
device_add+0xad2/0x16e0 drivers/base/core.c:2106
usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
really_probe+0x2da/0xb10 drivers/base/dd.c:509
driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
__device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
__device_attach+0x223/0x3a0 drivers/base/dd.c:844
bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
device_add+0xad2/0x16e0 drivers/base/core.c:2106
usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
hub_port_connect drivers/usb/core/hub.c:5089 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
port_event drivers/usb/core/hub.c:5350 [inline]
hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
kthread+0x313/0x420 kernel/kthread.c:253
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace 38ab7b2a1beef511 ]---
RIP: 0010:rtl_free_entries_from_scan_list
drivers/net/wireless/realtek/rtlwifi/base.c:1933 [inline]
RIP: 0010:rtl_deinit_core+0x84/0x2d0
drivers/net/wireless/realtek/rtlwifi/base.c:575
Code: 4c 89 f2 48 c1 ea 03 80 3c 02 00 0f 85 52 02 00 00 4d 8b bc 24 c8 c4
00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 22 02 00 00 4d 39 f7 4d 8b 2f 4c 89 ff 0f 84 3d
RSP: 0018:ffff8880a84b7278 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: 0000000000000001 RCX: 1ffffffff27960ab
RDX: 0000000000000000 RSI: ffffffff88da7445 RDI: ffff888093c00b68
RBP: ffff888093c00b20 R08: ffff8880a8498000 R09: ffffed101278051d
R10: ffffed101278051c R11: ffff888093c028e3 R12: ffff888093c02540
R13: ffff88821add7848 R14: ffff888093c0ea08 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8880ad000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd01db19000 CR3: 000000009c01a000 CR4: 00000000001406f0
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [RFC V4 1/2] mac80211: add hw 80211 encapsulation offloading support
From: Johannes Berg @ 2019-04-12 11:37 UTC (permalink / raw)
To: John Crispin, Kalle Valo
Cc: linux-wireless, Srini Kode, Rajkumar Manoharan,
Shashidhar Lakkavalli, Vasanthakumar Thiagarajan
In-Reply-To: <20190410073514.12794-2-john@phrozen.org>
On Wed, 2019-04-10 at 09:35 +0200, John Crispin wrote:
> The driver
> needs to enable the support on a per vif basis if it finds that all
> pre-reqs are meet.
> + * @IEEE80211_HW_SUPPORTS_80211_ENCAP: Hardware/driver supports 802.11
> + * encap for data frames.
I'm still not sure I can reconcile these ... why do you need the latter
if the driver has to enable per vif anyway?
> +int ieee80211_set_hw_80211_encap(struct ieee80211_vif *vif, bool enable);
Add documentation please. Would be better to return bool too, to be
symmetric.
> +++ b/net/mac80211/cfg.c
> @@ -2379,6 +2379,9 @@ static int ieee80211_set_wiphy_params(struct wiphy *wiphy, u32 changed)
> if (changed & WIPHY_PARAM_FRAG_THRESHOLD) {
> ieee80211_check_fast_xmit_all(local);
>
> + if (ieee80211_is_hw_80211_encap(local))
> + return -EINVAL;
Why not do this like TKIP and disable encap?
> +int ieee80211_set_hw_80211_encap(struct ieee80211_vif *vif, bool enable)
> +{
> + struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
> + struct ieee80211_local *local = sdata->local;
> +
> + if (enable == sdata->hw_80211_encap)
> + return enable;
It feels like this is missing some locking? Or at least a lock
assertion, if it's always called with a certain lock held already.
> + if (!sdata->dev)
> + return 0;
> +
> + if (!ieee80211_hw_check(&local->hw, SUPPORTS_80211_ENCAP))
> + enable = 0;
> +
> + switch (vif->type) {
> + case NL80211_IFTYPE_STATION:
> + if (sdata->u.mgd.use_4addr)
> + enable = 0;
> + break;
> + case NL80211_IFTYPE_AP_VLAN:
> + if (sdata->wdev.use_4addr)
> + enable = 0;
> + break;
> + default:
> + break;
> + }
> +
> + if (!ieee80211_hw_check(&local->hw, SUPPORTS_TX_FRAG) &&
> + (local->hw.wiphy->frag_threshold != (u32)-1))
> + enable = 0;
Shouldn't there be some kind of TKIP check here?
> +bool ieee80211_is_hw_80211_encap(struct ieee80211_local *local)
> +{
> + struct ieee80211_sub_if_data *sdata;
> + bool offloaded = false;
> +
> + mutex_lock(&local->iflist_mtx);
> + list_for_each_entry(sdata, &local->interfaces, list) {
> + if (sdata->hw_80211_encap) {
> + offloaded = true;
> + break;
> + }
> + }
> + mutex_unlock(&local->iflist_mtx);
This might be better with RCU, though for proper usage you'd actually
have to call it with the mutex held, otherwise it can change while
you're iterating ...
> + /* TKIP countermeasures wont work on encap offload mode */
> + if (key->conf.cipher == WLAN_CIPHER_SUITE_TKIP)
> + ieee80211_set_hw_80211_encap(&sdata->vif, 0);
false.
> @@ -197,6 +201,9 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
> key->conf.keyidx,
> sta ? sta->sta.addr : bcast_addr, ret);
>
> + if (sdata->hw_80211_encap)
> + return -EINVAL;
Yeah, and this means you're also missing a "do we have a SW crypto key
right now" check above in ieee80211_set_hw_80211_encap().
> + if (ieee80211_hw_check(hw, SUPPORTS_80211_ENCAP)) {
> + /* mac80211 always supports monitor unless we do 802.11
> + * encapsulation offloading.
> + */
> + hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_MONITOR);
> + hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_MONITOR);
> + }
Ok, maybe this addresses my question above about why we need both -
though it's not really clear what happens if the driver actually does
want to still enable monitor mode - which certainly we (iwlwifi) would.
> +void ieee80211_tx_status_8023(struct ieee80211_hw *hw,
> + struct ieee80211_vif *vif,
> + struct sk_buff *skb)
> +{
> + struct ieee80211_local *local = hw_to_local(hw);
> + struct ieee80211_sub_if_data *sdata;
> + struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> + struct sta_info *sta;
> + int retry_count;
> + int rates_idx;
> + bool acked;
> +
> + if (WARN_ON(!ieee80211_hw_check(hw, SUPPORTS_80211_ENCAP)))
> + goto skip_stats_update;
> +
> + sdata = vif_to_sdata(vif);
> +
> + acked = !!(info->flags & IEEE80211_TX_STAT_ACK);
no need for !! with bool :-)
> + /* check for driver support and ieee80211 encap offload */
> + if (!ieee80211_hw_check(&local->hw, SUPPORT_FAST_XMIT) ||
> + sdata->hw_80211_encap)
> return;
That comment isn't very useful? :-)
> @@ -3573,6 +3576,9 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
> goto begin;
> }
>
> + if (info->control.flags & IEEE80211_TX_CTRL_HW_80211_ENCAP)
> + goto encap_out;
> +
> if (test_bit(IEEE80211_TXQ_AMPDU, &txqi->flags))
> info->flags |= IEEE80211_TX_CTL_AMPDU;
Wouldn't you still want this flag, perhaps?
Not with ath10k I guess, which offloads aggregation sessions, but still?
That's not necessarily a requirement for encap offload, is it?
> + ieee80211_tx_stats(dev, skb->len);
> +
> + if (sta) {
> + sta->tx_stats.bytes[skb_get_queue_mapping(skb)] += skb->len;
> + sta->tx_stats.packets[skb_get_queue_mapping(skb)]++;
> + }
This is something to think about, aren't we usually doing that after
encapsulation? So the counters will be off a bit now?
> + if (WARN_ON(unlikely(!sdata->hw_80211_encap))) {
I feel I'm repeating myself - WARN_ON() includes unlikely().
johannes
^ permalink raw reply
* Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)
From: Johannes Berg @ 2019-04-12 11:19 UTC (permalink / raw)
To: Alexander Wetzel; +Cc: linux-wireless
In-Reply-To: <185ea9a2-f3c6-04a5-000b-44191da5a0ee@wetzel-home.de>
> AP-no-delay-client-HW-crypt.cap.gz
> same as above, only cleint using HW crypto
> You can e.g. find the "corrupted" looking frames with the wireshark filter
> "(wlan.fc.type_subtype == 0x0028) && !(llc.dsap == 0xaa)"
For everyone else - make sure to set "ignore protected bit - with IV" in
wireshark.
> Each capture here only has exactly one, the very first packet using the
> new key.
Yeah. Note that this packet is really quickly after the EAPOL 4/4
(1.5ms) so perhaps the key wasn't installed yet or something? Hmm, then
again, it should be before we send the confirmation?
But I don't know. The tracing would definitely tell me what's going on.
Btw, if you do record such tracing, it helps if you compile
wpa_supplicant with CONFIG_DEBUG_LINUX_TRACING and start it with the -T
argument to record all of its debugging into the trace file as well.
johannes
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v3 00/11] Add support for Orange Pi 3
From: Chen-Yu Tsai @ 2019-04-12 11:05 UTC (permalink / raw)
To: Ondřej Jirman
Cc: linux-sunxi, Maxime Ripard, Rob Herring, Linus Walleij,
David Airlie, Daniel Vetter, Mark Rutland, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, David S. Miller, Maxime Coquelin,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo, Naveen Gupta, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, netdev, linux-stm32,
linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
open list:GPIO SUBSYSTEM
In-Reply-To: <20190411101951.30223-1-megous@megous.com>
On Thu, Apr 11, 2019 at 6:19 PM megous via linux-sunxi
<linux-sunxi@googlegroups.com> wrote:
>
> From: Ondrej Jirman <megous@megous.com>
>
> This series implements support for Xunlong Orange Pi 3 board.
>
> Unfortunately, this board needs some small driver patches, so I have
> split the boards DT patch into chunks that require patches for drivers
> in various subsystems.
>
> Suggested merging plan/dependencies:
>
> - Pinctrl and stmmac patches are needed for ethernet support.
> (patches 1-5)
> - HDMI support was changed, please review. (patches 6-8)
> - brcmfmac patch 9, fixing firmware file selection, can be merged
> now, after review, as it doesn't depend on anything (please
> review :))
> - mmc1 pinconf (patch 10) can probably be merged now, too (it will
> certainly be used soon by all the other WiFi featuring boards
> based on H6)
> - WiFi dts patch will have to wait for H6 RTC patches, which in turn
> depend on ChenYu's RTC series, to be merged. That will take a
> while yet. I'm just keeping it in the series for completness.
> (patch 11)
Unfortunately I will not have time to tackle this for the next release.
Furthermore, I'd like to do this after the new clk parenting stuff lands.
Otherwise it's going to be a mess, as the clock tree is a bit convoluted
compared to previous SoCs.
ChenYu
^ permalink raw reply
* [PATCH] staging: remove redundant 'default n' from Kconfig
From: Bartlomiej Zolnierkiewicz @ 2019-04-12 10:13 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arve Hjønnevåg, Todd Kjos, Martijn Coenen,
Joel Fernandes, Christian Brauner, Mauro Carvalho Chehab,
Adham Abozaeid, Ajay Singh, devel, linux-kernel, linux-media,
linux-wireless
In-Reply-To: <CGME20190412101304eucas1p1178d633eb7aa83c46a9386384ba0c300@eucas1p1.samsung.com>
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:
...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:
config FOO
bool
config FOO
bool
default n
With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
drivers/staging/Kconfig | 1 -
drivers/staging/android/Kconfig | 2 --
drivers/staging/axis-fifo/Kconfig | 1 -
drivers/staging/gs_fpgaboot/Kconfig | 1 -
drivers/staging/media/Kconfig | 1 -
drivers/staging/media/rockchip/vpu/Kconfig | 1 -
drivers/staging/most/Kconfig | 1 -
drivers/staging/rtl8192e/Kconfig | 1 -
drivers/staging/wilc1000/Kconfig | 1 -
drivers/staging/wlan-ng/Kconfig | 1 -
10 files changed, 11 deletions(-)
Index: b/drivers/staging/Kconfig
===================================================================
--- a/drivers/staging/Kconfig 2019-04-12 12:04:20.794128367 +0200
+++ b/drivers/staging/Kconfig 2019-04-12 12:04:20.786128367 +0200
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
menuconfig STAGING
bool "Staging drivers"
- default n
---help---
This option allows you to select a number of drivers that are
not of the "normal" Linux kernel quality level. These drivers
Index: b/drivers/staging/android/Kconfig
===================================================================
--- a/drivers/staging/android/Kconfig 2019-04-12 12:04:20.794128367 +0200
+++ b/drivers/staging/android/Kconfig 2019-04-12 12:04:20.786128367 +0200
@@ -5,7 +5,6 @@ if ANDROID
config ASHMEM
bool "Enable the Anonymous Shared Memory Subsystem"
- default n
depends on SHMEM
help
The ashmem subsystem is a new shared memory allocator, similar to
@@ -17,7 +16,6 @@ config ASHMEM
config ANDROID_VSOC
tristate "Android Virtual SoC support"
- default n
depends on PCI_MSI
help
This option adds support for the Virtual SoC driver needed to boot
Index: b/drivers/staging/axis-fifo/Kconfig
===================================================================
--- a/drivers/staging/axis-fifo/Kconfig 2019-04-12 12:04:20.794128367 +0200
+++ b/drivers/staging/axis-fifo/Kconfig 2019-04-12 12:04:59.734129348 +0200
@@ -5,7 +5,6 @@
config XIL_AXIS_FIFO
tristate "Xilinx AXI-Stream FIFO IP core driver"
depends on OF
- default n
help
This adds support for the Xilinx AXI-Stream
FIFO IP core driver.
Index: b/drivers/staging/gs_fpgaboot/Kconfig
===================================================================
--- a/drivers/staging/gs_fpgaboot/Kconfig 2019-04-12 12:04:20.794128367 +0200
+++ b/drivers/staging/gs_fpgaboot/Kconfig 2019-04-12 12:04:20.790128367 +0200
@@ -4,6 +4,5 @@
#
config GS_FPGABOOT
tristate "Xilinx FPGA firmware download module"
- default n
help
Xilinx FPGA firmware download module
Index: b/drivers/staging/media/Kconfig
===================================================================
--- a/drivers/staging/media/Kconfig 2019-04-12 12:04:20.794128367 +0200
+++ b/drivers/staging/media/Kconfig 2019-04-12 12:05:05.470129493 +0200
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
menuconfig STAGING_MEDIA
bool "Media staging drivers"
- default n
help
This option allows you to select a number of media drivers that
don't have the "normal" Linux kernel quality level.
Index: b/drivers/staging/media/rockchip/vpu/Kconfig
===================================================================
--- a/drivers/staging/media/rockchip/vpu/Kconfig 2019-04-12 12:04:20.794128367 +0200
+++ b/drivers/staging/media/rockchip/vpu/Kconfig 2019-04-12 12:04:20.794128367 +0200
@@ -6,7 +6,6 @@ config VIDEO_ROCKCHIP_VPU
select VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_VMALLOC
select V4L2_MEM2MEM_DEV
- default n
help
Support for the Video Processing Unit present on Rockchip SoC,
which accelerates video and image encoding and decoding.
Index: b/drivers/staging/most/Kconfig
===================================================================
--- a/drivers/staging/most/Kconfig 2019-04-12 12:04:20.794128367 +0200
+++ b/drivers/staging/most/Kconfig 2019-04-12 12:04:20.794128367 +0200
@@ -2,7 +2,6 @@
menuconfig MOST
tristate "MOST support"
depends on HAS_DMA
- default n
---help---
Say Y here if you want to enable MOST support.
This driver needs at least one additional component to enable the
Index: b/drivers/staging/rtl8192e/Kconfig
===================================================================
--- a/drivers/staging/rtl8192e/Kconfig 2019-04-12 12:04:20.794128367 +0200
+++ b/drivers/staging/rtl8192e/Kconfig 2019-04-12 12:04:20.794128367 +0200
@@ -2,7 +2,6 @@
config RTLLIB
tristate "Support for rtllib wireless devices"
depends on WLAN && m
- default n
select LIB80211
help
If you have a wireless card that uses rtllib, say
Index: b/drivers/staging/wilc1000/Kconfig
===================================================================
--- a/drivers/staging/wilc1000/Kconfig 2019-04-12 12:04:20.794128367 +0200
+++ b/drivers/staging/wilc1000/Kconfig 2019-04-12 12:04:20.794128367 +0200
@@ -34,7 +34,6 @@ config WILC1000_SPI
config WILC1000_HW_OOB_INTR
bool "WILC1000 out of band interrupt"
depends on WILC1000_SDIO
- default n
help
This option enables out-of-band interrupt support for the WILC1000
chipset. This OOB interrupt is intended to provide a faster interrupt
Index: b/drivers/staging/wlan-ng/Kconfig
===================================================================
--- a/drivers/staging/wlan-ng/Kconfig 2019-04-12 12:04:20.794128367 +0200
+++ b/drivers/staging/wlan-ng/Kconfig 2019-04-12 12:04:20.794128367 +0200
@@ -4,7 +4,6 @@ config PRISM2_USB
depends on WLAN && USB && CFG80211
select WIRELESS_EXT
select WEXT_PRIV
- default n
help
This is the wlan-ng prism 2.5/3 USB driver for a wide range of
old USB wireless devices.
^ permalink raw reply
* Re: [PATCH v2] fq: fix fq_tin tx bytes overflow
From: Yibo Zhao @ 2019-04-12 10:09 UTC (permalink / raw)
To: Johannes Berg
Cc: ath10k, linux-wireless, Toke Høiland-Jørgensen,
linux-wireless-owner
In-Reply-To: <717acf1bde5507f73436ae7d45d114b34aee1c05.camel@sipsolutions.net>
On 2019-04-09 04:01, Johannes Berg wrote:
> On Mon, 2019-03-18 at 12:59 +0800, Yibo Zhao wrote:
>>
>> I understand your concern. Yes, I am using high end AP for throughput
>> test. I'd say 1.2 Gbps is not the worst case since we can achieve max
>> 1.4Gbps according to our test. AFAIK, for most throughput cases, 1min
>> is
>> the minimum requirement. And I think, with more and more high end
>> products(even higher throughput) on the ways to the market, it is
>> highly
>> possible that 30s is not a safe time before overflow.
>
> Well, 2 Gbps (goodput) would make it overflow every 16 seconds, so I'm
> not sure where you take the 1 minute from :-) Maybe from 1.2Gbps PHY
> rate.
>
> But still, the only place we expose this is debugfs, so I'm not really
> sure we want to spend that.
>
> Note that I'm generally pushing back on statistics right now - I really
> want to put some trace points or eBPF hooks in places that people can
> use to keep their favourite statistics, instead of trying to cover each
> and every use case in the stack itself.
Cool, great!looking forward to that change. :-)
>
> johannes
--
Yibo
^ permalink raw reply
* Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)
From: Johannes Berg @ 2019-04-12 9:51 UTC (permalink / raw)
To: Alexander Wetzel; +Cc: linux-wireless
In-Reply-To: <185ea9a2-f3c6-04a5-000b-44191da5a0ee@wetzel-home.de>
On Wed, 2019-04-10 at 22:46 +0200, Alexander Wetzel wrote:
> my new test AP came with a Intel AC-3168, which seems to use only one
> antenna, potentially also explaining my fist impression that it's a
> worse card for sniffing than my old Ultimate-N 6300.
Right, that's worse in some way.
> It looks like my (new) Wireless-AC 3168NGW (firmware 29.1044073957.0)
> does not have the new key ready for Rx when needed. I have a roughly 5 -
> 15 ms long window where the card scrambles received packets using the
> new key. (Note: I can't replicate that at the moment. May be wrong!)
> I first suspected the card "cleared" the new key for usage a bit too
> soon and tried to verify that by waiting a bit after installing a key to
> the HW. But it looks like it's not so simple...
>
> I've added a 40 ms delay in the mvm driver after the call to
> iwl_mvm_set_sta_key() and it first looked like that improved the
> situation. So I moved the sleep to iwl_trans_send_cmd() behind
> send_cmd() when not being in CMD_ASYNC but I can't see any any
> differences any longer. At the moment (with the new test setup) I always
> get one corrupted frame when downloading from the AP. Always the first
> frame using the new key...
Ok, that's interesting. Definitely something I'd want to reproduce here
locally and see where exactly we select the wrong key.
FWIW, no timing changes should be needed, once the firmware responds
(and we wait for that when installing a key) everything will be in
place.
> As for the test procedure: I just add a monitor interface in parallel to
> the "normal" interface on the AP. With HW encryption enabled we should
> only get cleartext packets and don't have to worry about encrypted
> packets in our capture at all:
> iw phy phy0 interface add mon0 type monitor
> ip link set up dev mon0
> And start a capture in the interface:
> tcpdump -pi mon0 -s0 -w /tmp/AP.cap
Right.
> I've just uploaded some captures for you to
> https://www.awhome.eu/index.php/s/AJJXBLsZmzHdxpX also. I've enabled
> swcrypto on the client for the first two and enabled HW crypto on the
> client again for the third and forth.
>
> AP-40ms.pcap.gz
> delay hack as outlined above on the AP
> AP-no-delay.cap.gz
> no hack (just some useless printks)
> AP-no-delay-client-HW-crypt.cap.gz
> same as above, only cleint using HW crypto
> AP-upload-no-delay-HW-crypt.cap.gz
> same as previous, only uploading instead of downloading.
> (and too many broken packets on receive, indicating a bad
> reception/sniffer card)
>
> In all captures I have a normal (1s) ping running to the AP from the
> cleint and start a download from an internal server after a while.
>
> You can e.g. find the "corrupted" looking frames with the wireshark filter
> "(wlan.fc.type_subtype == 0x0028) && !(llc.dsap == 0xaa)"
>
> Each capture here only has exactly one, the very first packet using the
> new key.
I'll take a look, but a trace-cmd recording would be more interesting
than the monitor interface, as it also tells us when what key was
installed etc.
If you have some time, you can find how to record that here (under the
"Tracing" section):
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging
Please do review the privacy notes there at the end of the page if you
do this, you should probably send the files to me/us directly rather
than post publicly. They do contain the keys of your (test) network to
some extent - at least of course the PTK(s)/GTK(s), but usually also the
KEK/KCK.
> When you look at the captures keep in mind that both the client and the
> AP also have the two not merged patches applied. But I do not see how
> that makes a difference here.
Agree.
johannes
^ permalink raw reply
* Re: iwlwifi: BUG: unable to handle kernel paging request at ffffc90000e1c808
From: Michal Hocko @ 2019-04-12 9:49 UTC (permalink / raw)
To: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, linux-wireless
Cc: LKML
In-Reply-To: <20190411210404.GC4743@dhcp22.suse.cz>
On Thu 11-04-19 23:07:20, Michal Hocko wrote:
> Hi,
> I have just encountered the following splat with 5.1-rc4. Is this a
> known problem? Greping throug older logs show that "Error sending SCAN_CFG_CMD"
> is not new. In older kernels it was followed by "Start IWL Error Log Dump:"
> but it oopsed now. I was running 5.0 previously. Let me know if you need
> more information.
FTR It happened again with 5.1.0-rc2-00001-ga3ac7917b730
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH 2/6] netlink: make validation more configurable for future strictness
From: Johannes Berg @ 2019-04-12 9:43 UTC (permalink / raw)
To: David Ahern, linux-wireless, netdev; +Cc: Pablo Neira Ayuso
In-Reply-To: <86911e8d-2818-67f8-058b-ab2f4db33e55@cumulusnetworks.com>
On Wed, 2019-04-10 at 09:55 -0700, David Ahern wrote:
> On 4/3/19 11:54 PM, Johannes Berg wrote:
> > @@ -280,6 +287,12 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
> > break;
> >
> > case NLA_UNSPEC:
> > + if (validate & NL_VALIDATE_UNSPEC) {
> > + NL_SET_ERR_MSG_ATTR(extack, nla,
> > + "Attribute not understood");
>
> I found that confusing when I did a trial run for a new route attribute.
> How about "Unsupported attribute"?
Sure, makes sense. I've changed it in my branch (mac80211-next tree,
netlink-validation branch).
johannes
^ permalink raw reply
* Re: NL80211_SCAN_FLAG_RANDOM_ADDR ?
From: Sergey Matyukevich @ 2019-04-12 9:26 UTC (permalink / raw)
To: Denis Kenzior; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <e09a9bc7-9774-334b-53e8-13e1d781bee3@gmail.com>
> I've been poking around at how this flag is used and I noticed this
> check in net/wireless/nl80211.c:
>
> nl80211_check_scan_flags()
>
> if (*flags & NL80211_SCAN_FLAG_RANDOM_ADDR) {
> int err;
>
> if (!(wiphy->features & randomness_flag) ||
> (wdev && wdev->current_bss))
> return -EOPNOTSUPP;
>
>
> The above disallows the use of RANDOM_ADDR for scans while connected.
> The nl80211.h uapi header seems to concur:
>
> "@NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR: This device/driver supports
> using a random MAC address during scan (if the device is unassociated);"
>
> However, if I create a P2P Device (in addition to the default STA
> device), the kernel happily lets me scan on the wdev while the STA
> interface is connected.
>
> sudo iw phy0 interface add p2p type __p2pdev
> sudo iw wdev 0x2 p2p start
> sudo iw wdev 0x2 scan randomize
>
> So the immediate question I have is, should the RANDOM_ADDR flag indeed
> be limited to unassociated STA interfaces? It would seem the hardware
> is capable randomizing even when connected? Please educate me :)
Hello Denis,
IIUC, this feature could be introduced to support Android Compatibility
Definition Document (CDD). Those documents are available at the
following page: https://source.android.com/compatibility/cdd
For instance, in the latest CDD randomized scan requirements are described
in the section 7.4.2. It looks like current high level nl80211 API follows
those recommendations. Probably it has been implemented with STA use-case
in mind, that is why you can use that flag for P2P connection. But, as
Ben pointed out, actual application of this flag may depend on
implementation in firwmare and hardware.
Regards,
Sergey
^ permalink raw reply
* [PATCH v2] ath10k: Remove ATH10K_STATE_RESTARTED in simulate fw crash
From: Wen Gong @ 2019-04-12 8:52 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
When test simulate firmware crash, it is easy to trigger error.
command:
echo soft > /sys/kernel/debug/ieee80211/phyxx/ath10k/simulate_fw_crash.
If input more than two times continuously, then it will have error.
Error message:
ath10k_pci 0000:02:00.0: failed to set vdev 1 RX wake policy: -108
ath10k_pci 0000:02:00.0: device is wedged, will not restart
It is because the state has not changed to ATH10K_STATE_ON immediately,
then it will have more than two simulate crash process running meanwhile,
and complete/wakeup some field twice, it destroy the normal recovery
process.
add flag wait-ready for this command:
echo soft wait-ready > /sys/kernel/debug/ieee80211/phyxx/ath10k/simulate_fw_crash
Tested with QCA6174 PCI with firmware
WLAN.RM.4.4.1-00109-QCARMSWPZ-1, but this will also affect QCA9377 PCI.
It's not a regression with new firmware releases.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
---
v2: add wait-ready flag
drivers/net/wireless/ath/ath10k/debug.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 15964b3..04a20b8 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -534,7 +534,8 @@ static ssize_t ath10k_read_simulate_fw_crash(struct file *file,
"`soft` - this will send WMI_FORCE_FW_HANG_ASSERT to firmware if FW supports that command.\n"
"`hard` - this will send to firmware command with illegal parameters causing firmware crash.\n"
"`assert` - this will send special illegal parameter to firmware to cause assert failure and crash.\n"
- "`hw-restart` - this will simply queue hw restart without fw/hw actually crashing.\n";
+ "`hw-restart` - this will simply queue hw restart without fw/hw actually crashing.\n"
+ "`soft wait-ready` `hard wait-ready` `assert wait-ready` `hw-restart wait-ready` - cmd only execuate when state is ATH10K_STATE_ON.\n";
return simple_read_from_buffer(user_buf, count, ppos, buf, strlen(buf));
}
@@ -554,6 +555,9 @@ static ssize_t ath10k_write_simulate_fw_crash(struct file *file,
char buf[32] = {0};
ssize_t rc;
int ret;
+ char buf_cmd[32] = {0};
+ char buf_flag[32] = {0};
+ bool wait_ready;
/* filter partial writes and invalid commands */
if (*ppos != 0 || count >= sizeof(buf) || count == 0)
@@ -567,18 +571,25 @@ static ssize_t ath10k_write_simulate_fw_crash(struct file *file,
if (buf[*ppos - 1] == '\n')
buf[*ppos - 1] = '\0';
+ sscanf(buf, "%s %s", buf_cmd, buf_flag);
+ ath10k_info(ar, "buf_cmd:%s, buf_flag:%s\n", buf_cmd, buf_flag);
+
+ wait_ready = !strcmp(buf_cmd, "wait-ready");
mutex_lock(&ar->conf_mutex);
- if (ar->state != ATH10K_STATE_ON &&
- ar->state != ATH10K_STATE_RESTARTED) {
+ if ((!wait_ready &&
+ ar->state != ATH10K_STATE_ON &&
+ ar->state != ATH10K_STATE_RESTARTED) ||
+ (wait_ready &&
+ ar->state != ATH10K_STATE_ON)) {
ret = -ENETDOWN;
goto exit;
}
- if (!strcmp(buf, "soft")) {
+ if (!strcmp(buf_cmd, "soft")) {
ath10k_info(ar, "simulating soft firmware crash\n");
ret = ath10k_wmi_force_fw_hang(ar, WMI_FORCE_FW_HANG_ASSERT, 0);
- } else if (!strcmp(buf, "hard")) {
+ } else if (!strcmp(buf_cmd, "hard")) {
ath10k_info(ar, "simulating hard firmware crash\n");
/* 0x7fff is vdev id, and it is always out of range for all
* firmware variants in order to force a firmware crash.
@@ -586,10 +597,10 @@ static ssize_t ath10k_write_simulate_fw_crash(struct file *file,
ret = ath10k_wmi_vdev_set_param(ar, 0x7fff,
ar->wmi.vdev_param->rts_threshold,
0);
- } else if (!strcmp(buf, "assert")) {
+ } else if (!strcmp(buf_cmd, "assert")) {
ath10k_info(ar, "simulating firmware assert crash\n");
ret = ath10k_debug_fw_assert(ar);
- } else if (!strcmp(buf, "hw-restart")) {
+ } else if (!strcmp(buf_cmd, "hw-restart")) {
ath10k_info(ar, "user requested hw restart\n");
queue_work(ar->workqueue, &ar->restart_work);
ret = 0;
--
1.9.1
^ permalink raw reply related
* Re: [RFC/RFT] mac80211: Switch to a virtual time-based airtime scheduler
From: Yibo Zhao @ 2019-04-12 6:34 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: make-wifi-fast, linux-wireless, Felix Fietkau, Rajkumar Manoharan,
Kan Yan, linux-wireless-owner
In-Reply-To: <877ec0u6mu.fsf@toke.dk>
On 2019-04-11 19:24, Toke Høiland-Jørgensen wrote:
> Yibo Zhao <yiboz@codeaurora.org> writes:
>
>> On 2019-04-10 18:40, Toke Høiland-Jørgensen wrote:
>>> Yibo Zhao <yiboz@codeaurora.org> writes:
>>>
>>>> On 2019-04-10 04:41, Toke Høiland-Jørgensen wrote:
>>>>> Yibo Zhao <yiboz@codeaurora.org> writes:
>>>>>
>>>>>> On 2019-04-04 16:31, Toke Høiland-Jørgensen wrote:
>>>>>>> Yibo Zhao <yiboz@codeaurora.org> writes:
>>>>>>>
>>>>>>>> On 2019-02-16 01:05, Toke Høiland-Jørgensen wrote:
>>>>>>>>> This switches the airtime scheduler in mac80211 to use a
>>>>>>>>> virtual
>>>>>>>>> time-based
>>>>>>>>> scheduler instead of the round-robin scheduler used before.
>>>>>>>>> This
>>>>>>>>> has
>>>>>>>>> a
>>>>>>>>> couple of advantages:
>>>>>>>>>
>>>>>>>>> - No need to sync up the round-robin scheduler in
>>>>>>>>> firmware/hardware
>>>>>>>>> with
>>>>>>>>> the round-robin airtime scheduler.
>>>>>>>>>
>>>>>>>>> - If several stations are eligible for transmission we can
>>>>>>>>> schedule
>>>>>>>>> both of
>>>>>>>>> them; no need to hard-block the scheduling rotation until the
>>>>>>>>> head
>>>>>>>>> of
>>>>>>>>> the
>>>>>>>>> queue has used up its quantum.
>>>>>>>>>
>>>>>>>>> - The check of whether a station is eligible for transmission
>>>>>>>>> becomes
>>>>>>>>> simpler (in ieee80211_txq_may_transmit()).
>>>>>>>>>
>>>>>>>>> The drawback is that scheduling becomes slightly more
>>>>>>>>> expensive,
>>>>>>>>> as
>>>>>>>>> we
>>>>>>>>> need
>>>>>>>>> to maintain an rbtree of TXQs sorted by virtual time. This
>>>>>>>>> means
>>>>>>>>> that
>>>>>>>>> ieee80211_register_airtime() becomes O(logN) in the number of
>>>>>>>>> currently
>>>>>>>>> scheduled TXQs. However, hopefully this number rarely grows too
>>>>>>>>> big
>>>>>>>>> (it's
>>>>>>>>> only TXQs currently backlogged, not all associated stations),
>>>>>>>>> so
>>>>>>>>> it
>>>>>>>>> shouldn't be too big of an issue.
>>>>>>>>>
>>>>>>>>> @@ -1831,18 +1830,32 @@ void
>>>>>>>>> ieee80211_sta_register_airtime(struct
>>>>>>>>> ieee80211_sta *pubsta, u8 tid,
>>>>>>>>> {
>>>>>>>>> struct sta_info *sta = container_of(pubsta, struct sta_info,
>>>>>>>>> sta);
>>>>>>>>> struct ieee80211_local *local = sta->sdata->local;
>>>>>>>>> + struct ieee80211_txq *txq = sta->sta.txq[tid];
>>>>>>>>> u8 ac = ieee80211_ac_from_tid(tid);
>>>>>>>>> - u32 airtime = 0;
>>>>>>>>> + u64 airtime = 0, weight_sum;
>>>>>>>>> +
>>>>>>>>> + if (!txq)
>>>>>>>>> + return;
>>>>>>>>>
>>>>>>>>> if (sta->local->airtime_flags & AIRTIME_USE_TX)
>>>>>>>>> airtime += tx_airtime;
>>>>>>>>> if (sta->local->airtime_flags & AIRTIME_USE_RX)
>>>>>>>>> airtime += rx_airtime;
>>>>>>>>>
>>>>>>>>> + /* Weights scale so the unit weight is 256 */
>>>>>>>>> + airtime <<= 8;
>>>>>>>>> +
>>>>>>>>> spin_lock_bh(&local->active_txq_lock[ac]);
>>>>>>>>> +
>>>>>>>>> sta->airtime[ac].tx_airtime += tx_airtime;
>>>>>>>>> sta->airtime[ac].rx_airtime += rx_airtime;
>>>>>>>>> - sta->airtime[ac].deficit -= airtime;
>>>>>>>>> +
>>>>>>>>> + weight_sum = local->airtime_weight_sum[ac] ?:
>>>>>>>>> sta->airtime_weight;
>>>>>>>>> +
>>>>>>>>> + local->airtime_v_t[ac] += airtime / weight_sum;
>>>>>>>> Hi Toke,
>>>>>>>>
>>>>>>>> Please ignore the previous two broken emails regarding this new
>>>>>>>> proposal
>>>>>>>> from me.
>>>>>>>>
>>>>>>>> It looks like local->airtime_v_t acts like a Tx criteria. Only
>>>>>>>> the
>>>>>>>> stations with less airtime than that are valid for Tx. That
>>>>>>>> means
>>>>>>>> there
>>>>>>>> are situations, like 50 clients, that some of the stations can
>>>>>>>> be
>>>>>>>> used
>>>>>>>> to Tx when putting next_txq in the loop. Am I right?
>>>>>>>
>>>>>>> I'm not sure what you mean here. Are you referring to the case
>>>>>>> where
>>>>>>> new
>>>>>>> stations appear with a very low (zero) airtime_v_t? That is
>>>>>>> handled
>>>>>>> when
>>>>>>> the station is enqueued.
>>>>>> Hi Toke,
>>>>>>
>>>>>> Sorry for the confusion. I am not referring to the case that you
>>>>>> mentioned though it can be solved by your subtle design, max(local
>>>>>> vt,
>>>>>> sta vt). :-)
>>>>>>
>>>>>> Actually, my concern is situation about putting next_txq in the
>>>>>> loop.
>>>>>> Let me explain a little more and see below.
>>>>>>
>>>>>>> @@ -3640,126 +3638,191 @@ EXPORT_SYMBOL(ieee80211_tx_dequeue);
>>>>>>> struct ieee80211_txq *ieee80211_next_txq(struct ieee80211_hw
>>>>>>> *hw,
>>>>>>> u8
>>>>>>> ac)
>>>>>>> {
>>>>>>> struct ieee80211_local *local = hw_to_local(hw);
>>>>>>> + struct rb_node *node = local->schedule_pos[ac];
>>>>>>> struct txq_info *txqi = NULL;
>>>>>>> + bool first = false;
>>>>>>>
>>>>>>> lockdep_assert_held(&local->active_txq_lock[ac]);
>>>>>>>
>>>>>>> - begin:
>>>>>>> - txqi = list_first_entry_or_null(&local->active_txqs[ac],
>>>>>>> - struct txq_info,
>>>>>>> - schedule_order);
>>>>>>> - if (!txqi)
>>>>>>> + if (!node) {
>>>>>>> + node = rb_first_cached(&local->active_txqs[ac]);
>>>>>>> + first = true;
>>>>>>> + } else
>>>>>>> + node = rb_next(node);
>>>>>>
>>>>>> Consider below piece of code from ath10k_mac_schedule_txq:
>>>>>>
>>>>>> ieee80211_txq_schedule_start(hw, ac);
>>>>>> while ((txq = ieee80211_next_txq(hw, ac))) {
>>>>>> while (ath10k_mac_tx_can_push(hw, txq)) {
>>>>>> ret = ath10k_mac_tx_push_txq(hw, txq);
>>>>>> if (ret < 0)
>>>>>> break;
>>>>>> }
>>>>>> ieee80211_return_txq(hw, txq);
>>>>>> ath10k_htt_tx_txq_update(hw, txq);
>>>>>> if (ret == -EBUSY)
>>>>>> break;
>>>>>> }
>>>>>> ieee80211_txq_schedule_end(hw, ac);
>>>>>>
>>>>>> If my understanding is right, local->schedule_pos is used to
>>>>>> record
>>>>>> the
>>>>>> last scheduled node and used for traversal rbtree for valid txq.
>>>>>> There
>>>>>> is chance that an empty txq is feeded to return_txq and got
>>>>>> removed
>>>>>> from
>>>>>> rbtree. The empty txq will always be the rb_first node. Then in
>>>>>> the
>>>>>> following next_txq, local->schedule_pos becomes meaningless since
>>>>>> its
>>>>>> rb_next will return NULL and the loop break. Only rb_first get
>>>>>> dequeued
>>>>>> during this loop.
>>>>>>
>>>>>> if (!node || RB_EMPTY_NODE(node)) {
>>>>>> node = rb_first_cached(&local->active_txqs[ac]);
>>>>>> first = true;
>>>>>> } else
>>>>>> node = rb_next(node);
>>>>>
>>>>> Ah, I see what you mean. Yes, that would indeed be a problem - nice
>>>>> catch! :)
>>>>>
>>>>>> How about this? The nodes on the rbtree will be dequeued and
>>>>>> removed
>>>>>> from rbtree one by one until HW is busy. Please note local vt and
>>>>>> sta
>>>>>> vt will not be updated since txq lock is held during this time.
>>>>>
>>>>> Insertion and removal from the rbtree are relatively expensive, so
>>>>> I'd
>>>>> rather not do that for every txq. I think a better way to solve
>>>>> this
>>>>> is to just defer the actual removal from the tree until
>>>>> ieee80211_txq_schedule_end()... Will fix that when I submit this
>>>>> again.
>>>>
>>>> Do you mean we keep the empty txqs in the rbtree until loop finishes
>>>> and
>>>> remove them in ieee80211_txq_schedule_end(may be put return_txq in
>>>> it)?
>>>> If it is the case, I suppose a list is needed to store the empty
>>>> txqs
>>>> so
>>>> as to dequeue them in ieee80211_txq_schedule_end.
>>>
>>> Yeah, return_txq() would just put "to be removed" TXQs on a list, and
>>> schedule_end() would do the actual removal (after checking whether a
>>> new
>>> packet showed up in the meantime).
>>
>> SGTM
>>
>>>
>>>> And one more thing,
>>>>
>>>>> + if (sta->airtime[ac].v_t > local->airtime_v_t[ac])
>>>>> {
>>>>> + if (first)
>>>>> + local->airtime_v_t[ac] =
>>>>> sta->airtime[ac].v_t;
>>>>> + else
>>>>> + return NULL;
>>>>
>>>> As local->airtime_v_t will not be updated during loop, we don't need
>>>> to
>>>> return NULL.
>>>
>>> Yes we do; this is actually the break condition. I.e., stations whose
>>> virtual time are higher than the global time (in local->airtime_v_t)
>>> are
>>> not allowed to transmit. And since we are traversing them in order,
>>> when
>>> we find the first such station, we are done and can break out of the
>>> scheduling loop entirely (which is what we do by returning NULL). The
>>> other branch in the inner if() is just for the case where no stations
>>> are currently eligible to transmit according to this rule; here we
>>> don't
>>> want to stall, so we advance the global timer so the first station
>>> becomes eligible...
>>
>> Yes，the inner if() make sure first node always get scheduled no matter
>> its vt.
>>
>> To detail my concern, let's assume only two nodes in the tree and
>> empty nodes will be in tree until schedule_end(). In the loop and in
>> case hw is not busy, ath10k will drain every node next_txq returned
>> before asking for another txq again. Then as we are traversing to next
>> rb node, it is highly possible the second node is not allowed to
>> transmit since the global time has not been updated yet as the active
>> txq lock is held. At this time, only second node on the tree has data
>> and hw is capable of sending more data. I don't think the second node
>> is not valid for transmission in this situation.
>>
>> With more nodes in the tree in this situation, I think same thing
>> happens that all nodes except the first node are not allowed to
>> transmit since none of their vts are less than the global time which
>> is not updated in time. The loop breaks when we are checking the
>> second node.
>
> Yeah, in many cases we will end up throttling all but the first (couple
> of) node(s). This is by design; otherwise we can't ensure fairness. As
> long as we are making forward progress that is fine, though...
All right, I see your point. Fairness is our first priority. :)
>
> -Toke
--
Yibo
^ permalink raw reply
* Re: [RFC V4 2/2] ath10k: add tx hw 802.11 encapusaltion offloading support
From: Kalle Valo @ 2019-04-12 3:56 UTC (permalink / raw)
To: John Crispin
Cc: Johannes Berg, linux-wireless, Srini Kode, Rajkumar Manoharan,
Shashidhar Lakkavalli, Vasanthakumar Thiagarajan
In-Reply-To: <3ffaff0b-3d5c-1413-3f95-13d8430a62fc@phrozen.org>
John Crispin <john@phrozen.org> writes:
> On 10/04/2019 17:31, Kalle Valo wrote:
>> John Crispin <john@phrozen.org> writes:
>>
>>> From: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
>>>
>>> This patch adds support for ethernet rxtx mode to the driver. The feature
>>> is enabled via a new module parameter. If enabled to driver will enable
>>> the feature on a per vif basis if all other requirements were met.
>>>
>>> Testing on a IPQ4019 based hardware shows a increase in TCP throughput
>>> of ~20% when the feature is enabled.
>>>
>>> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
>>> Signed-off-by: John Crispin <john@phrozen.org>
>> Looks good to me.
>>
>> BTW, for ath10k patches (patchsets including ath10k patches) please try
>> to CC also the ath10k list. Easier to find ath10k patches that way.
>>
> Hi,
>
> Thanks Kalle, I'll be sending a V5 tomorrow with a small improvement
> on the hw crypto part, that unbreaks wpa3. can I add your Acked-by on
> the ath10k part ?
Adding my Acked-by is not necessary as I will be applying the ath10k
patch anyway. In these cases we usually do so that Johannes applies the
mac80211 part, he then assigns the driver patches to me in patchwork,
and once mac80211 commits are in my tree, I'll apply the driver part.
--
Kalle Valo
^ permalink raw reply
* Re: NL80211_SCAN_FLAG_RANDOM_ADDR ?
From: Ben Greear @ 2019-04-12 2:15 UTC (permalink / raw)
To: Denis Kenzior, linux-wireless
In-Reply-To: <ce4f4f2b-ad34-fbf6-6fcb-0b95cf9b9d24@gmail.com>
On 04/11/2019 06:26 PM, Denis Kenzior wrote:
> Hi Ben,
>
> On 04/11/2019 06:20 PM, Ben Greear wrote:
>> On 4/11/19 4:19 PM, Ben Greear wrote:
>>> On 4/11/19 3:30 PM, Denis Kenzior wrote:
>>>> Hi,
>>>>
>>>> I've been poking around at how this flag is used and I noticed this check in net/wireless/nl80211.c:
>>>>
>>>> nl80211_check_scan_flags()
>>>>
>>>> if (*flags & NL80211_SCAN_FLAG_RANDOM_ADDR) {
>>>> int err;
>>>>
>>>> if (!(wiphy->features & randomness_flag) ||
>>>> (wdev && wdev->current_bss))
>>>> return -EOPNOTSUPP;
>>>>
>>>>
>>>> The above disallows the use of RANDOM_ADDR for scans while connected. The nl80211.h uapi header seems to concur:
>>>>
>>>> "@NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR: This device/driver supports using a random MAC address during scan (if the device is unassociated);"
>>>>
>>>> However, if I create a P2P Device (in addition to the default STA device), the kernel happily lets me scan on the wdev while the STA interface is connected.
>>>>
>>>> sudo iw phy0 interface add p2p type __p2pdev
>>>> sudo iw wdev 0x2 p2p start
>>>> sudo iw wdev 0x2 scan randomize
>>>>
>>>> So the immediate question I have is, should the RANDOM_ADDR flag indeed be limited to unassociated STA interfaces? It would seem the hardware is capable randomizing even when connected? Please educate me :)
>>>
>>> You can be sure that each driver/hardware has its own bugs and limitations related to this.
>>>
>>> Ath10k wave 1 and wave 2 that I am aware of would ignore and/or not ACK probe responses
>>> sent back to an MAC address that is not that of the station itself. And changing the mac of a station
>>> would require complete re-association AFAIK. That is likely just one of the many issues.
>
> Yes, I understand that some hardware would not support this. But the question is does this check belong at the nl80211 layer (e.g. no hardware can do this) vs somewhere at the driver layer + additional feature bit as needed.
>
>>
>> I should add: If you really want to scan in this manner, you could just create a new station vdev with
>> random addr and have it do the scanning, then delete it when done? The original station will continue on
>> its way unmolested.
>>
>
> So you mean something like:
> sudo iw phy0 interface add sta2 type station
> sudo iw dev sta2 scan randomize
> command failed: Network is down (-100)
> sudo ifconfig sta2 up
> SIOCSIFFLAGS: Device or resource busy
>
> I guess I'm running into this:
>
> valid interface combinations:
> * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 1, #{ P2P-device } <= 1,
> total <= 3, #channels <= 2
>
> Or did you mean something else?
You got my meaning, I guess your driver cannot support it. It should work with ath10k,
at least the versions I use.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: NL80211_SCAN_FLAG_RANDOM_ADDR ?
From: Denis Kenzior @ 2019-04-12 1:26 UTC (permalink / raw)
To: Ben Greear, linux-wireless
In-Reply-To: <fcd9fcc2-86dd-8cd7-1822-efb7df498cf8@candelatech.com>
Hi Ben,
On 04/11/2019 06:20 PM, Ben Greear wrote:
> On 4/11/19 4:19 PM, Ben Greear wrote:
>> On 4/11/19 3:30 PM, Denis Kenzior wrote:
>>> Hi,
>>>
>>> I've been poking around at how this flag is used and I noticed this
>>> check in net/wireless/nl80211.c:
>>>
>>> nl80211_check_scan_flags()
>>>
>>> if (*flags & NL80211_SCAN_FLAG_RANDOM_ADDR) {
>>> int err;
>>>
>>> if (!(wiphy->features & randomness_flag) ||
>>> (wdev && wdev->current_bss))
>>> return -EOPNOTSUPP;
>>>
>>>
>>> The above disallows the use of RANDOM_ADDR for scans while connected.
>>> The nl80211.h uapi header seems to concur:
>>>
>>> "@NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR: This device/driver supports
>>> using a random MAC address during scan (if the device is unassociated);"
>>>
>>> However, if I create a P2P Device (in addition to the default STA
>>> device), the kernel happily lets me scan on the wdev while the STA
>>> interface is connected.
>>>
>>> sudo iw phy0 interface add p2p type __p2pdev
>>> sudo iw wdev 0x2 p2p start
>>> sudo iw wdev 0x2 scan randomize
>>>
>>> So the immediate question I have is, should the RANDOM_ADDR flag
>>> indeed be limited to unassociated STA interfaces? It would seem the
>>> hardware is capable randomizing even when connected? Please educate
>>> me :)
>>
>> You can be sure that each driver/hardware has its own bugs and
>> limitations related to this.
>>
>> Ath10k wave 1 and wave 2 that I am aware of would ignore and/or not
>> ACK probe responses
>> sent back to an MAC address that is not that of the station itself.
>> And changing the mac of a station
>> would require complete re-association AFAIK. That is likely just one
>> of the many issues.
Yes, I understand that some hardware would not support this. But the
question is does this check belong at the nl80211 layer (e.g. no
hardware can do this) vs somewhere at the driver layer + additional
feature bit as needed.
>
> I should add: If you really want to scan in this manner, you could just
> create a new station vdev with
> random addr and have it do the scanning, then delete it when done? The
> original station will continue on
> its way unmolested.
>
So you mean something like:
sudo iw phy0 interface add sta2 type station
sudo iw dev sta2 scan randomize
command failed: Network is down (-100)
sudo ifconfig sta2 up
SIOCSIFFLAGS: Device or resource busy
I guess I'm running into this:
valid interface combinations:
* #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 1, #{ P2P-device
} <= 1,
total <= 3, #channels <= 2
Or did you mean something else?
Regards,
-Denis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox