* [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
* Re: [RFC 0/8] nl80211: add 6GHz band support
From: Arend Van Spriel @ 2019-06-21 19:41 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <6d40e69c-0cea-cc92-7974-c54d0f70812e@broadcom.com>
On 6/3/2019 12:39 PM, Arend Van Spriel wrote:
> On 5/27/2019 10:46 PM, Arend Van Spriel wrote:
>> On 5/24/2019 8:38 PM, Arend Van Spriel wrote:
>>> On May 24, 2019 1:56:43 PM Johannes Berg <johannes@sipsolutions.net>
>>> wrote:
>>>
>>>> Hi Arend,
>>>>
>>>> On Mon, 2019-05-20 at 14:00 +0200, Arend van Spriel wrote:
>>>>> In 802.11ax D4.0 a new band has been proposed. This series contains
>>>>> changes to cfg80211 for supporting this band. With 2GHz and 5GHz there
>>>>> was no overlap in channel number. However, this new band has channel
>>>>> numbers with a range from 1 up to 253.
>>>>
>>>> At the wireless workshop in Prague, we looked at this and sort of
>>>> decided that it'd be better to put all the 6 GHz channels into the 5
>>>> GHz
>>>> "band" in nl80211, to avoid all the "5 || 6" since they're really the
>>>> same except for very specific places like scanning.
>>>
>>> Would have liked to be there, but attending is no longer an option
>>> for me. We now have two autistic, non-verbal children and I am the
>>> primary caregiver for the oldest because my wife can't handle him.
>>> Guess I should have checked the workshop notes before working on this
>>> :-) Do you have URL?
>>
>> Found the netdev wifi workshop page and looked over the slides
>> quickly, but the notes page is pretty empty ;-)
>>
>>> Agree that most functional requirements for 6 GHz are same as 5 GHz.
>>> There are some 6 GHz specifics about beaconing as well.
>>
>> This came up in discussion with my colleagues today and I would say
>> from mac80211 perspective there is more to it than just scanning. In
>> short the 6GHz band is for HE-only operation so for example only HE
>> rates may be used. As the bitrates are in ieee80211_supported_band
>> having a separate 6GHz band seems to have a (slight?) advantage.
>
> Hi, Johannes
>
> Any thoughts on this?
Hi Johannes,
It has been a while so maybe your thoughts are more concrete? ;-p
I really would like this to move forward as I also noticed hostapd
changes being posted for 6GHz support yesterday.
Thanks,
Arend
^ permalink raw reply
* Re: iwlwifi/brcmfmac public action frames crash (RESENDING)
From: Denis Kenzior @ 2019-06-21 20:09 UTC (permalink / raw)
To: linux-wireless, Johannes Berg; +Cc: Arend Van Spriel
In-Reply-To: <45805272aaf8b872a90cf0c364164b5fc1b20272.camel@linux.intel.com>
Ping, is anyone looking into these crashes?
On 06/13/2019 11:45 AM, James Prestwood wrote:
> Sorry if this comes in twice, I sent it ~12 hours ago but never saw it
> hit the list, nor in the archives so I am resending it.
>
> Hi,
>
> Both iwlwifi/brcmfmac seem to be unable to send public action frames to
> an unassociated AP. I am attempting to do a GAS ANQP request with a
> public action frame (via CMD_FRAME). Immediately after CMD_FRAME any of
> the following happens depending on the card:
>
> Intel 7260 (iwlwifi) - System lockup freeze (must hard reboot)
> Intel 3160 (iwlwifi) - CMD_FRAME returns -EINVAL
> BCM43602 (brcmfmac) - Kernel crash (below)
> AR9462 (ath9k) - works
> Random USB adapter (rt2800usb) - works
>
> iwlwifi (on 7260) completely locks the system, where the only way to
> recover is hard reboot. I have reproduced this on two separate systems,
> both with a 7260. I *have* seen it not lock the system once although
> lately it seems to happen every time. The 3160 did not cause a hang
> with my limited testing, though it did not accept CMD_FRAME which is
> likely why it never hung.
>
> Not sure how I can get any more info about the iwlwifi problem as the
> system is completely hung, but if there is a way I'll be happy to do
> that.
>
> Here is the brcmfmac crash:
>
> [19735.643941] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000000
> [19735.643965] PGD 80000001874aa067 P4D 80000001874aa067 PUD 2735fe067
> PMD 0
> [19735.643984] Oops: 0000 [#1] SMP PTI
> [19735.643993] CPU: 7 PID: 5051 Comm: iwd Tainted: G W
> I 4.19.0-rc2-custom #27
> [19735.644002] Hardware name: System manufacturer System Product
> Name/SABERTOOTH X58, BIOS 1402 08/09/2012
> [19735.644027] RIP: 0010:brcmf_p2p_send_action_frame+0x23a/0x850
> [brcmfmac]
> [19735.644037] Code: 41 c7 86 e0 00 00 00 00 00 00 00 f0 41 80 66 20 bf
> f0 41 80 66 20 7f 49 8b 46 48 b9 24 07 00 00 48 89 da 48 c7 c6 3d 00 8f
> c0 <48> 8b 38 e8 3e d7 ff ff 85 c0 41 89 c5 0f 85 c4 00 00 00 8b 03 49
> [19735.644051] RSP: 0018:ffffa879c8477a00 EFLAGS: 00010246
> [19735.644059] RAX: 0000000000000000 RBX: ffff954a2e059000 RCX:
> 0000000000000724
> [19735.644067] RDX: ffff954a2e059000 RSI: ffffffffc08f003d RDI:
> 0000000000000002
> [19735.644075] RBP: ffffa879c8477a50 R08: 000000000000001c R09:
> 0000000000000999
> [19735.644083] R10: ffff954b157a2f00 R11: ffffffffc0720000 R12:
> ffff954c32f26021
> [19735.644091] R13: ffff954a2e059000 R14: ffff954c32f26000 R15:
> 00000000ffffffff
> [19735.644099] FS: 00007f8d5aa30740(0000) GS:ffff954c369c0000(0000)
> knlGS:0000000000000000
> [19735.644108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [19735.644115] CR2: 0000000000000000 CR3: 00000001845c8000 CR4:
> 00000000000006e0
> [19735.644123] Call Trace:
> [19735.644133] ? _cond_resched+0x19/0x40
> [19735.644153] brcmf_cfg80211_mgmt_tx+0x170/0x2f0 [brcmfmac]
> [19735.644192] cfg80211_mlme_mgmt_tx+0x115/0x2f0 [cfg80211]
> [19735.644219] nl80211_tx_mgmt+0x24d/0x3d0 [cfg80211]
> [19735.644228] genl_family_rcv_msg+0x1fe/0x3f0
> [19735.644237] ? nlmon_xmit+0x2c/0x30
> [19735.644246] ? dev_hard_start_xmit+0xa8/0x210
> [19735.644254] genl_rcv_msg+0x4c/0x90
> [19735.644261] ? genl_family_rcv_msg+0x3f0/0x3f0
> [19735.644268] netlink_rcv_skb+0x54/0x130
> [19735.644275] genl_rcv+0x28/0x40
> [19735.644281] netlink_unicast+0x1ab/0x250
> [19735.644288] netlink_sendmsg+0x2d1/0x3d0
> [19735.644297] sock_sendmsg+0x3e/0x50
> [19735.644304] __sys_sendto+0x13f/0x180
> [19735.644313] ? do_epoll_wait+0xb0/0xc0
> [19735.644321] __x64_sys_sendto+0x28/0x30
> [19735.644329] do_syscall_64+0x5a/0x120
> [19735.644336] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [19735.644344] RIP: 0033:0x7f8d5a352c4d
> [19735.644350] Code: ff ff ff ff eb b6 0f 1f 80 00 00 00 00 48 8d 05 c1
> dc 2c 00 41 89 ca 8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2c 00 00 00 0f
> 05 <48> 3d 00 f0 ff ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41
> [19735.644365] RSP: 002b:00007ffc9a618048 EFLAGS: 00000246 ORIG_RAX:
> 000000000000002c
> [19735.644374] RAX: ffffffffffffffda RBX: 00000000007077d0 RCX:
> 00007f8d5a352c4d
> [19735.644382] RDX: 0000000000000068 RSI: 000000000072bc40 RDI:
> 0000000000000004
> [19735.644390] RBP: 0000000000733510 R08: 0000000000000000 R09:
> 0000000000000000
> [19735.644397] R10: 0000000000000000 R11: 0000000000000246 R12:
> 00007ffc9a618094
> [19735.644405] R13: 00007ffc9a61809c R14: 0000000000000000 R15:
> 0000000000000000
> [19735.644414] Modules linked in: ccm algif_aead snd_hda_codec_realtek
> snd_hda_codec_generic snd_hda_codec_hdmi binfmt_misc arc4 nouveau
> gpio_ich ath9k mxm_wmi ath9k_common video rt2800usb intel_powerclamp
> snd_hda_intel ath9k_hw rt2x00usb iwlmvm rt2800lib snd_hda_codec
> rt2x00lib ath snd_seq_midi snd_seq_midi_event coretemp ttm mac80211
> snd_hda_core brcmfmac snd_hwdep snd_rawmidi iwlwifi intel_cstate
> drm_kms_helper brcmutil snd_seq drm snd_pcm input_leds serio_raw
> lpc_ich cfg80211 snd_seq_device i2c_algo_bit snd_timer fb_sys_fops
> syscopyarea sysfillrect snd sysimgblt i5500_temp wmi asus_atk0110
> soundcore mac_hid i7core_edac sch_fq_codel kvm_intel kvm vfio_pci
> vfio_virqfd irqbypass vfio_iommu_type1 vfio pci_stub parport_pc ppdev
> lp parport ip_tables x_tables autofs4 pata_acpi hid_generic usbhid hid
> firewire_ohci
> [19735.644521] realtek psmouse firewire_core crc_itu_t r8169 i2c_i801
> ahci libahci
> [19735.644538] CR2: 0000000000000000
> [19735.653612] ---[ end trace 30dbecd734da3b73 ]---
> [19735.653641] RIP: 0010:brcmf_p2p_send_action_frame+0x23a/0x850
> [brcmfmac]
> [19735.653651] Code: 41 c7 86 e0 00 00 00 00 00 00 00 f0 41 80 66 20 bf
> f0 41 80 66 20 7f 49 8b 46 48 b9 24 07 00 00 48 89 da 48 c7 c6 3d 00 8f
> c0 <48> 8b 38 e8 3e d7 ff ff 85 c0 41 89 c5 0f 85 c4 00 00 00 8b 03 49
> [19735.653659] RSP: 0018:ffffa879c8477a00 EFLAGS: 00010246
> [19735.653672] RAX: 0000000000000000 RBX: ffff954a2e059000 RCX:
> 0000000000000724
> [19735.653680] RDX: ffff954a2e059000 RSI: ffffffffc08f003d RDI:
> 0000000000000002
> [19735.653688] RBP: ffffa879c8477a50 R08: 000000000000001c R09:
> 0000000000000999
> [19735.653697] R10: ffff954b157a2f00 R11: ffffffffc0720000 R12:
> ffff954c32f26021
> [19735.653705] R13: ffff954a2e059000 R14: ffff954c32f26000 R15:
> 00000000ffffffff
> [19735.653714] FS: 00007f8d5aa30740(0000) GS:ffff954c369c0000(0000)
> knlGS:0000000000000000
> [19735.653725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [19735.653731] CR2: 0000000000000000 CR3: 00000001845c8000 CR4:
> 00000000000006e0
>
> Thanks,
> James
>
^ permalink raw reply
* [PATCH] mt76: move nl80211_dfs_regions in mt76_dev data structure
From: Lorenzo Bianconi @ 2019-06-21 20:31 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless
Move dfs region field in mt76_dev data structure since it is
used by all drivers. This is a preliminary patch to add DFS support to
mt7615 driver
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76.h | 2 ++
.../net/wireless/mediatek/mt76/mt7603/debugfs.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt7603/init.c | 4 ++--
.../net/wireless/mediatek/mt76/mt7603/mt7603.h | 2 --
.../net/wireless/mediatek/mt76/mt76x02_debugfs.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c | 16 ++++++++--------
drivers/net/wireless/mediatek/mt76/mt76x02_dfs.h | 2 --
7 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 9110a895604a..2c107817610c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -486,6 +486,8 @@ struct mt76_dev {
int txpower_conf;
int txpower_cur;
+ enum nl80211_dfs_regions region;
+
u32 debugfs_reg;
struct led_classdev led_cdev;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c
index 9c0bea489e1f..a1bc3103cbe9 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c
@@ -49,7 +49,7 @@ mt7603_edcca_set(void *data, u64 val)
dev->ed_monitor_enabled = !!val;
dev->ed_monitor = dev->ed_monitor_enabled &&
- dev->region == NL80211_DFS_ETSI;
+ dev->mt76.region == NL80211_DFS_ETSI;
mt7603_init_edcca(dev);
mutex_unlock(&dev->mt76.mutex);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/init.c b/drivers/net/wireless/mediatek/mt76/mt7603/init.c
index bce51997ff3b..75e3da452585 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/init.c
@@ -437,9 +437,9 @@ mt7603_regd_notifier(struct wiphy *wiphy,
struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
struct mt7603_dev *dev = hw->priv;
- dev->region = request->dfs_region;
+ dev->mt76.region = request->dfs_region;
dev->ed_monitor = dev->ed_monitor_enabled &&
- dev->region == NL80211_DFS_ETSI;
+ dev->mt76.region == NL80211_DFS_ETSI;
}
static int
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h b/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h
index 944dc9a11a15..eb5c4880342b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h
@@ -118,8 +118,6 @@ struct mt7603_dev {
u8 mcu_running;
- enum nl80211_dfs_regions region;
-
u8 ed_monitor_enabled;
u8 ed_monitor;
s8 ed_trigger;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c b/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c
index ffdba5ffc22d..1b1e424ccbb2 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_debugfs.c
@@ -120,7 +120,7 @@ static int
mt76_edcca_set(void *data, u64 val)
{
struct mt76x02_dev *dev = data;
- enum nl80211_dfs_regions region = dev->dfs_pd.region;
+ enum nl80211_dfs_regions region = dev->mt76.region;
mutex_lock(&dev->mt76.mutex);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c b/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c
index 84b845647881..50e9b310e496 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c
@@ -283,7 +283,7 @@ static bool mt76x02_dfs_check_hw_pulse(struct mt76x02_dev *dev,
if (!pulse->period || !pulse->w1)
return false;
- switch (dev->dfs_pd.region) {
+ switch (dev->mt76.region) {
case NL80211_DFS_FCC:
if (pulse->engine > 3)
break;
@@ -457,7 +457,7 @@ static int mt76x02_dfs_create_sequence(struct mt76x02_dev *dev,
with_sum = event->width + cur_event->width;
sw_params = &dfs_pd->sw_dpd_params;
- switch (dev->dfs_pd.region) {
+ switch (dev->mt76.region) {
case NL80211_DFS_FCC:
case NL80211_DFS_JP:
if (with_sum < 600)
@@ -685,7 +685,7 @@ static void mt76x02_dfs_init_sw_detector(struct mt76x02_dev *dev)
{
struct mt76x02_dfs_pattern_detector *dfs_pd = &dev->dfs_pd;
- switch (dev->dfs_pd.region) {
+ switch (dev->mt76.region) {
case NL80211_DFS_FCC:
dfs_pd->sw_dpd_params.max_pri = MT_DFS_FCC_MAX_PRI;
dfs_pd->sw_dpd_params.min_pri = MT_DFS_FCC_MIN_PRI;
@@ -725,7 +725,7 @@ static void mt76x02_dfs_set_bbp_params(struct mt76x02_dev *dev)
break;
}
- switch (dev->dfs_pd.region) {
+ switch (dev->mt76.region) {
case NL80211_DFS_FCC:
radar_specs = &fcc_radar_specs[shift];
break;
@@ -836,7 +836,7 @@ void mt76x02_dfs_init_params(struct mt76x02_dev *dev)
struct cfg80211_chan_def *chandef = &dev->mt76.chandef;
if ((chandef->chan->flags & IEEE80211_CHAN_RADAR) &&
- dev->dfs_pd.region != NL80211_DFS_UNSET) {
+ dev->mt76.region != NL80211_DFS_UNSET) {
mt76x02_dfs_init_sw_detector(dev);
mt76x02_dfs_set_bbp_params(dev);
/* enable debug mode */
@@ -869,7 +869,7 @@ void mt76x02_dfs_init_detector(struct mt76x02_dev *dev)
INIT_LIST_HEAD(&dfs_pd->sequences);
INIT_LIST_HEAD(&dfs_pd->seq_pool);
- dfs_pd->region = NL80211_DFS_UNSET;
+ dev->mt76.region = NL80211_DFS_UNSET;
dfs_pd->last_sw_check = jiffies;
tasklet_init(&dfs_pd->dfs_tasklet, mt76x02_dfs_tasklet,
(unsigned long)dev);
@@ -882,14 +882,14 @@ mt76x02_dfs_set_domain(struct mt76x02_dev *dev,
struct mt76x02_dfs_pattern_detector *dfs_pd = &dev->dfs_pd;
mutex_lock(&dev->mt76.mutex);
- if (dfs_pd->region != region) {
+ if (dev->mt76.region != region) {
tasklet_disable(&dfs_pd->dfs_tasklet);
dev->ed_monitor = dev->ed_monitor_enabled &&
region == NL80211_DFS_ETSI;
mt76x02_edcca_init(dev);
- dfs_pd->region = region;
+ dev->mt76.region = region;
mt76x02_dfs_init_params(dev);
tasklet_enable(&dfs_pd->dfs_tasklet);
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.h b/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.h
index 70b394e17340..0408613b45a4 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_dfs.h
@@ -118,8 +118,6 @@ struct mt76x02_dfs_seq_stats {
};
struct mt76x02_dfs_pattern_detector {
- enum nl80211_dfs_regions region;
-
u8 chirp_pulse_cnt;
u32 chirp_pulse_ts;
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] nl80211: Limit certain commands to interface owner
From: Arend Van Spriel @ 2019-06-21 21:16 UTC (permalink / raw)
To: Denis Kenzior, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <af810765-ba1a-c7ae-abe5-35eef72eb8ce@gmail.com>
On 6/21/2019 7:14 PM, Denis Kenzior wrote:
> 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?
hmm. I tried searching in memory... of my email client but to no avail.
I somehow recalled that netlink multicast was not guaranteed to be
delivered/seen by all listeners.
>> "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 ;)
That's just it, right. This is what Marcel calls the real environment,
but is it. The nl80211 is a kernel API and should that mean that there
must be a managing daemon locking down APIs for other user-space tools
to use. If I want a user-space app to show a radar screen with
surrounding APs using scanning and FTM nl80211 commands it seems now it
has to create a new interface and hope the resources are there for it to
succeed. Where is my freedom in that? If I am using such an app don't
you think I don't accept it could impact the managing daemon.
>> 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 ;)
Probably. One of my concerns was about NL80211_CMD_CONNECT event, but
checking nl80211_send_connect_result() it seems to just send it to the
mlme multicast group regardless SOCKET_OWNER use.
>> 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?
Not saying that. Just saying that the "real environment" is in the eye
of the beholder and it would be nice if there was a way to opt out, but
Marcel seems strongly opposed to it. So there seems no point in
scratching that itch and come up with a patch.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH v2 2/3] nl80211: Limit certain commands to interface owner
From: Denis Kenzior @ 2019-06-21 22:33 UTC (permalink / raw)
To: Arend Van Spriel, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <b1ae8df6-c8a7-e453-aad3-e31bb2e3bd60@broadcom.com>
Hi Arend,
>>> "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 ;)
>
> That's just it, right. This is what Marcel calls the real environment,
> but is it. The nl80211 is a kernel API and should that mean that there
> must be a managing daemon locking down APIs for other user-space tools
> to use. If I want a user-space app to show a radar screen with
> surrounding APs using scanning and FTM nl80211 commands it seems now it
> has to create a new interface and hope the resources are there for it to
> succeed. Where is my freedom in that? If I am using such an app don't
> you think I don't accept it could impact the managing daemon.
I get it. But on the flip side, should the managing daemon accept you
messing with it? I mean there is a definite associated cost here,
whether it is stuff crashing, having to account for extra corner cases
and race conditions, giving out erroneous results, etc.
As Marcel pointed out, the proper solution is to do this via some
diagnostic interface on the managing daemon, so it can properly manage
such requests to not interfere with whatever else is going on.
By the way, the above would be generally useful to many people, so if
you have some code lying around... ;)
>>> 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?
>
> Not saying that. Just saying that the "real environment" is in the eye
> of the beholder and it would be nice if there was a way to opt out, but
> Marcel seems strongly opposed to it. So there seems no point in
> scratching that itch and come up with a patch.
>
I guess the question is, what do you want this for? If you want this
for pure manual testing and accept the consequence of the managing
daemon crashing, giving erroneous results or being otherwise confused?
If you're fine with the above, I don't see a problem with such a patch.
Regards,
-Denis
^ permalink raw reply
* Re: [PATCH v2 2/3] nl80211: Limit certain commands to interface owner
From: Marcel Holtmann @ 2019-06-22 13:44 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: Denis Kenzior, Johannes Berg, linux-wireless
In-Reply-To: <b1ae8df6-c8a7-e453-aad3-e31bb2e3bd60@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
>> ??? 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?
>
> hmm. I tried searching in memory... of my email client but to no avail. I somehow recalled that netlink multicast was not guaranteed to be delivered/seen by all listeners.
>
>>> "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 ;)
>
> That's just it, right. This is what Marcel calls the real environment, but is it. The nl80211 is a kernel API and should that mean that there must be a managing daemon locking down APIs for other user-space tools to use. If I want a user-space app to show a radar screen with surrounding APs using scanning and FTM nl80211 commands it seems now it has to create a new interface and hope the resources are there for it to succeed. Where is my freedom in that? If I am using such an app don't you think I don't accept it could impact the managing daemon.
if you are operating on a shared radio resource you have to have some way of ensuring that nobody steals resources from you. Having an external application that will also use scanning and other off-channel operation will result in a bad experience. Especially if it involves scanning. Currently we still have 3 or more parties triggering scanning on nl80211. Essentially they are now fighting for radio time. You have wpa_supplicant scanning, you have NetworkManager scanning and you have the UI scanning. Now adding just another application that just scans at its decided time location / direction finding is not helping the situation.
If our kernel cfg80211 / nl80211 would be smart enough to handle these concurrent tasks, I would have little objection to let all clients do whatever they want, but we don’t have that. I do not want an external application messing with my planned radio time. And frankly if I am in the middle of roaming, I don’t want to be delayed because some fancy radar looking UI decides to start a full spectrum scan or blocks us via an action frame that times out.
With iwd we are moving towards the direction that we are utilizing the information from access points and surrounding networks to intelligently scan and reduce the time spent scanning to a minimum. For us that is the way to improve WiFi experience for Linux.
We have been through this with Bluetooth already years ago. You need a central daemon that watches out for your radio utilization. Doing anything behind the back of such a daemon is not going to work out long term. Same applies to 2G/3G/LTE where even more tasks need to be managed. And even wpa_supplicant has an internal mutex to control radio time.
Regards
Marcel
^ permalink raw reply
* Re: iwlwifi/brcmfmac public action frames crash (RESENDING)
From: Arend Van Spriel @ 2019-06-23 6:06 UTC (permalink / raw)
To: Denis Kenzior, linux-wireless, Johannes Berg
In-Reply-To: <07c7b5fc-bc1c-d49f-1c1e-d0b67899e755@gmail.com>
On June 21, 2019 10:09:10 PM Denis Kenzior <denkenz@gmail.com> wrote:
> Ping, is anyone looking into these crashes?
Did not see this message before.
>
> On 06/13/2019 11:45 AM, James Prestwood wrote:
>> Sorry if this comes in twice, I sent it ~12 hours ago but never saw it
>> hit the list, nor in the archives so I am resending it.
>>
>>
>> Hi,
[snip]
>>
>>
>>
>>
>> Here is the brcmfmac crash:
>>
>>
>> [19735.643941] BUG: unable to handle kernel NULL pointer dereference at
>> 0000000000000000
>> [19735.643965] PGD 80000001874aa067 P4D 80000001874aa067 PUD 2735fe067
>> PMD 0
>> [19735.643984] Oops: 0000 [#1] SMP PTI
>> [19735.643993] CPU: 7 PID: 5051 Comm: iwd Tainted: G W
>> I 4.19.0-rc2-custom #27
>> [19735.644002] Hardware name: System manufacturer System Product
>> Name/SABERTOOTH X58, BIOS 1402 08/09/2012
>> [19735.644027] RIP: 0010:brcmf_p2p_send_action_frame+0x23a/0x850
>> [brcmfmac]
As the name suggest this was implemented for P2P support. Will look into this.
Regards,
Arend
^ permalink raw reply
* Re: iwlwifi module crash
From: b.K.il.h.u+tigbuh @ 2019-06-23 9:08 UTC (permalink / raw)
To: Balakrishnan Balasubramanian; +Cc: Emmanuel Grumbach, linux-wireless
In-Reply-To: <CAPuHQ=Ffq_Gw_KbyjpzR07MWz=+LxmGVEP2-Tn5zDxrUEuxrZQ@mail.gmail.com>
devices/ is probably just a symlink. Try to find it manually:
find /sys -iname remove
lspci
The interesting thing is that my iwlwifi card started to do the same
thing just recently (some weeks ago). However, I do suspend a lot and
it only happens after resuming, but not after every resume (maybe
5-10%). It always came back after restarting except on one day when it
needed three restarts, so maybe mine would be more about needing to
reseat the card.
> On Fri, Jun 14, 2019 at 4:54 AM Balakrishnan Balasubramanian <linux-wireless-list@balki.me> wrote:
>>
>> The issue occured again today. I tried to restart the module
>>
>> > echo 1 > /sys/module/iwlwifi/devices/0000\:02\:00.0/remove
>>
>> There is no folder 'devices'
>>
>> zadesk% ls /sys/module/iwlwifi
>> coresize drivers holders initsize initstate notes parameters refcnt
>> sections srcversion taint uevent
>>
>> > echo 1 > /sys/bus/pci/rescan
>>
>> Attached the error when trying to rescan.
>>
>> Thanks,
>> Bala
>>
>>
>>
>>
^ permalink raw reply
* Re: [PATCH] wireless: wil6210: no need to check return value of debugfs_create functions
From: merez @ 2019-06-23 12:55 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Kalle Valo, David S. Miller, linux-wireless, wil6210,
linux-wireless-owner
In-Reply-To: <20190611191024.GA17227@kroah.com>
On 2019-06-11 22:10, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Maya Erez <merez@codeaurora.org>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: linux-wireless@vger.kernel.org
> Cc: wil6210@qti.qualcomm.com
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/net/wireless/ath/wil6210/debugfs.c | 80 ++++++----------------
> 1 file changed, 22 insertions(+), 58 deletions(-)
>
Reviewed-by: Maya Erez <merez@codeaurora.org>
--
Maya Erez
Qualcomm Israel, Inc. on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] mt76: mt76u: get rid of {out,in}_max_packet
From: Lorenzo Bianconi @ 2019-06-23 20:25 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, sgruszka
Remove {out,in}_max_packet from mt76_usb data structure since
they just track last usb endpoint and they are not actually used
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76.h | 2 --
drivers/net/wireless/mediatek/mt76/usb.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 27f5dfb8c77f..2c107817610c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -397,9 +397,7 @@ struct mt76_usb {
struct delayed_work stat_work;
u8 out_ep[__MT_EP_OUT_MAX];
- u16 out_max_packet;
u8 in_ep[__MT_EP_IN_MAX];
- u16 in_max_packet;
bool sg_en;
struct mt76u_mcu {
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index ecc1aa59f5c1..fb87ce7fbdf6 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -267,12 +267,10 @@ mt76u_set_endpoints(struct usb_interface *intf,
if (usb_endpoint_is_bulk_in(ep_desc) &&
in_ep < __MT_EP_IN_MAX) {
usb->in_ep[in_ep] = usb_endpoint_num(ep_desc);
- usb->in_max_packet = usb_endpoint_maxp(ep_desc);
in_ep++;
} else if (usb_endpoint_is_bulk_out(ep_desc) &&
out_ep < __MT_EP_OUT_MAX) {
usb->out_ep[out_ep] = usb_endpoint_num(ep_desc);
- usb->out_max_packet = usb_endpoint_maxp(ep_desc);
out_ep++;
}
}
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] nl80211: Limit certain commands to interface owner
From: Arend Van Spriel @ 2019-06-24 8:39 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Denis Kenzior, Johannes Berg, linux-wireless
In-Reply-To: <011C968F-507F-4646-B206-C28BDE7EB4A0@holtmann.org>
On 6/22/2019 3:44 PM, Marcel Holtmann wrote:
> 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
>>> ??? 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?
>>
>> hmm. I tried searching in memory... of my email client but to no avail. I somehow recalled that netlink multicast was not guaranteed to be delivered/seen by all listeners.
>>
>>>> "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 ;)
>>
>> That's just it, right. This is what Marcel calls the real environment, but is it. The nl80211 is a kernel API and should that mean that there must be a managing daemon locking down APIs for other user-space tools to use. If I want a user-space app to show a radar screen with surrounding APs using scanning and FTM nl80211 commands it seems now it has to create a new interface and hope the resources are there for it to succeed. Where is my freedom in that? If I am using such an app don't you think I don't accept it could impact the managing daemon.
>
> if you are operating on a shared radio resource you have to have some way of ensuring that nobody steals resources from you. Having an external application that will also use scanning and other off-channel operation will result in a bad experience. Especially if it involves scanning. Currently we still have 3 or more parties triggering scanning on nl80211. Essentially they are now fighting for radio time. You have wpa_supplicant scanning, you have NetworkManager scanning and you have the UI scanning. Now adding just another application that just scans at its decided time location / direction finding is not helping the situation.
My app was just a hypothetical example. I understand your conundrum, but
my point was that you can not know how a system is configured. Now for
the SOCKET_OWNER I should say it does not provide you any guarantees. At
best it improves your chances. With the nl80211 API being as it is, you
can not rule out multiple application controlling the same device. The
virtual interfaces can be guarded with SOCKET_OWNER, but in the end
there is still one physical device and only if you are lucky you may
come across a device with two physical radios, but most of them just
have one. If you really want to be in control we should allow only one
socket or at least only one "control" socket.
> If our kernel cfg80211 / nl80211 would be smart enough to handle these concurrent tasks, I would have little objection to let all clients do whatever they want, but we don’t have that. I do not want an external application messing with my planned radio time. And frankly if I am in the middle of roaming, I don’t want to be delayed because some fancy radar looking UI decides to start a full spectrum scan or blocks us via an action frame that times out.
The have been some efforts to handle concurrent use. For scheduled scan
concurrency was added and critical proto primitives allow to temporarily
disable scans when user-space needs it, eg. for EAPOL or DHCP exchange.
> With iwd we are moving towards the direction that we are utilizing the information from access points and surrounding networks to intelligently scan and reduce the time spent scanning to a minimum. For us that is the way to improve WiFi experience for Linux.
>
> We have been through this with Bluetooth already years ago. You need a central daemon that watches out for your radio utilization. Doing anything behind the back of such a daemon is not going to work out long term. Same applies to 2G/3G/LTE where even more tasks need to be managed. And even wpa_supplicant has an internal mutex to control radio time.
Right. Given how nl80211 works today the only real control of radio time
would need to be done in kernel space or go for the one "control" socket
approach.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] Add SPDX identifiers
From: Kalle Valo @ 2019-06-24 9:01 UTC (permalink / raw)
To: yegorslists; +Cc: linux-wireless, johannes
In-Reply-To: <20190620130148.1674-1-yegorslists@googlemail.com>
yegorslists@googlemail.com writes:
> 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>
For patches to iw it's good practise to prefix the title with "iw: ",
that way people can immediately see for which component it is. But no
need to resend because of this.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] Add SPDX identifiers
From: Johannes Berg @ 2019-06-24 9:45 UTC (permalink / raw)
To: yegorslists, linux-wireless
In-Reply-To: <20190620130148.1674-1-yegorslists@googlemail.com>
On Thu, 2019-06-20 at 15:01 +0200, yegorslists@googlemail.com wrote:
> From: Yegor Yefremov <yegorslists@googlemail.com>
>
> Software Package Data Exchange identifiers help to detect source file
> licenses and hence simplify the FOSS compliance process.
Well that's nice and all, but it's also wrong.
You haven't included any documentation that says what the SPDX
identifier, and specifically the "ISC" tag means in the context of the
project, and it's not even the same license text as on spdx.org.
johannes
^ permalink raw reply
* Re: [PATCH] Add SPDX identifiers
From: Yegor Yefremov @ 2019-06-24 10:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <90ccc515bb26b212b537fc1b0287afaa0f86fdf8.camel@sipsolutions.net>
On Mon, Jun 24, 2019 at 11:45 AM Johannes Berg
<johannes@sipsolutions.net> wrote:
>
> On Thu, 2019-06-20 at 15:01 +0200, yegorslists@googlemail.com wrote:
> > From: Yegor Yefremov <yegorslists@googlemail.com>
> >
> > Software Package Data Exchange identifiers help to detect source file
> > licenses and hence simplify the FOSS compliance process.
>
> Well that's nice and all, but it's also wrong.
>
> You haven't included any documentation that says what the SPDX
> identifier, and specifically the "ISC" tag means in the context of the
> project, and it's not even the same license text as on spdx.org.
What about such definition?
SPDX short-form identifiers provide information about licenses that
apply to the source file.
As for the exact license I wasn't sure myself. Buildroot identifies it
as ISC [1]. How do you define its license in SPDX terms?
[1] https://git.busybox.net/buildroot/tree/package/iw/iw.mk
Yegor
^ permalink raw reply
* Re: [PATCH] Add SPDX identifiers
From: Johannes Berg @ 2019-06-24 10:36 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: linux-wireless
In-Reply-To: <CAGm1_ksic4xcVdaPAObwwNdaQ19E3ZiK97SkmVmp8kz6H2KpOw@mail.gmail.com>
> > You haven't included any documentation that says what the SPDX
> > identifier, and specifically the "ISC" tag means in the context of the
> > project, and it's not even the same license text as on spdx.org.
>
> What about such definition?
>
> SPDX short-form identifiers provide information about licenses that
> apply to the source file.
It just bothers me that this isn't self-contained - you always have to
go to spdx.org to really figure out what it means.
> As for the exact license I wasn't sure myself. Buildroot identifies it
> as ISC [1]. How do you define its license in SPDX terms?
Not sure. Maybe you cannot?
spdx.org says "ISC" is the license that says:
[...] THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS [...]
while the license here says:
[...] THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS [...]
(and the same in one other place)
This might just be an oversight on spdx.org, since the license with "THE
AUTHOR" *is* typically referred to as "ISC" (e.g.
https://opensource.org/licenses/ISC), but it still means it's not
actually identical?
Maybe spdx.org should switch, but then it changing the license text ...
what if anyone refers to it already?
It's all not very obvious to me.
The kernel side-stepped it and said "let's make it all self-contained",
which seems saner to me.
johannes
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in p54u_load_firmware_cb
From: Andrey Konovalov @ 2019-06-24 11:51 UTC (permalink / raw)
To: Christian Lamparter
Cc: Alan Stern, syzbot, Christian Lamparter, David S. Miller,
Kalle Valo, Kernel development list, USB list, linux-wireless,
netdev, syzkaller-bugs
In-Reply-To: <3232861.cjm3rXpEJU@debian64>
On Thu, Jun 20, 2019 at 9:56 PM Christian Lamparter <chunkeey@gmail.com> wrote:
>
> 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/>
Yes, until this patch is in the tree that is being tested (which is
based on the usb-linus branch; I update it every few weeks), syzbot
considers this bug as open.
>
> Regards,
> Christian
>
>
^ permalink raw reply
* Re: [PATCH 1/3] iwlwifi: add new cards for 22000 and fix struct name
From: Kalle Valo @ 2019-06-24 13:19 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Ihab Zhaika, Luca Coelho
In-Reply-To: <20190614084852.386-2-luca@coelho.fi>
Luca Coelho <luca@coelho.fi> wrote:
> From: Ihab Zhaika <ihab.zhaika@intel.com>
>
> add few PCI ID'S for 22000 and fix the wrong name for one
> of the structs
>
> Signed-off-by: Ihab Zhaika <ihab.zhaika@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Patch applied to wireless-drivers.git, thanks.
d151b0a2efa1 iwlwifi: add new cards for 22000 and fix struct name
--
https://patchwork.kernel.org/patch/10994725/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 2/3] iwlwifi: add new cards for 22000 and change wrong structs
From: Kalle Valo @ 2019-06-24 13:20 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Ihab Zhaika, Luca Coelho
In-Reply-To: <20190619175902.16053-1-luca@coelho.fi>
Luca Coelho <luca@coelho.fi> wrote:
> From: Ihab Zhaika <ihab.zhaika@intel.com>
>
> add few PCI ID'S for 22000 and chainge few cards structs names
>
> Signed-off-by: Ihab Zhaika <ihab.zhaika@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Patch applied to wireless-drivers.git, thanks.
a976bfb44bdb iwlwifi: add new cards for 22000 and change wrong structs
--
https://patchwork.kernel.org/patch/11004991/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 3/3] iwlwifi: change 0x02F0 fw from qu to quz
From: Kalle Valo @ 2019-06-24 13:21 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Ihab Zhaika, Luca Coelho
In-Reply-To: <20190614084852.386-4-luca@coelho.fi>
Luca Coelho <luca@coelho.fi> wrote:
> From: Ihab Zhaika <ihab.zhaika@intel.com>
>
> change the fw of 0x02F0 platform from qu to quz
>
> Signed-off-by: Ihab Zhaika <ihab.zhaika@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Patch applied to wireless-drivers.git, thanks.
658521fc1bf1 iwlwifi: change 0x02F0 fw from qu to quz
--
https://patchwork.kernel.org/patch/10994727/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] wl18xx: Fix Wunused-const-variable
From: Kalle Valo @ 2019-06-24 13:22 UTC (permalink / raw)
To: Nathan Huckleberry
Cc: davem, linux-wireless, netdev, linux-kernel, Nathan Huckleberry,
clang-built-linux
In-Reply-To: <20190614171713.89262-1-nhuck@google.com>
Nathan Huckleberry <nhuck@google.com> wrote:
> Clang produces the following warning
>
> drivers/net/wireless/ti/wl18xx/main.c:1850:43: warning: unused variable
> 'wl18xx_iface_ap_cl_limits' [-Wunused-const-variable] static const struct
> ieee80211_iface_limit wl18xx_iface_ap_cl_limits[] = { ^
> drivers/net/wireless/ti/wl18xx/main.c:1869:43: warning: unused variable
> 'wl18xx_iface_ap_go_limits' [-Wunused-const-variable] static const struct
> ieee80211_iface_limit wl18xx_iface_ap_go_limits[] = { ^
>
> The commit that added these variables never used them. Removing them.
>
> Cc: clang-built-linux@googlegroups.com
> Link: https://github.com/ClangBuiltLinux/linux/issues/530
> Signed-off-by: Nathan Huckleberry <nhuck@google.com>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Patch applied to wireless-drivers.git, thanks.
608fd7214323 wl18xx: Fix Wunused-const-variable
--
https://patchwork.kernel.org/patch/10996073/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 5.2 1/2] mwifiex: Don't abort on small, spec-compliant vendor IEs
From: Kalle Valo @ 2019-06-24 13:23 UTC (permalink / raw)
To: Brian Norris
Cc: Ganapathi Bhat, Nishant Sarmukadam, Amitkumar Karwar, Xinming Hu,
linux-kernel, linux-wireless, Takashi Iwai, Guenter Roeck,
Brian Norris
In-Reply-To: <20190615001321.241808-1-briannorris@chromium.org>
Brian Norris <briannorris@chromium.org> wrote:
> Per the 802.11 specification, vendor IEs are (at minimum) only required
> to contain an OUI. A type field is also included in ieee80211.h (struct
> ieee80211_vendor_ie) but doesn't appear in the specification. The
> remaining fields (subtype, version) are a convention used in WMM
> headers.
>
> Thus, we should not reject vendor-specific IEs that have only the
> minimum length (3 bytes) -- we should skip over them (since we only want
> to match longer IEs, that match either WMM or WPA formats). We can
> reject elements that don't have the minimum-required 3 byte OUI.
>
> While we're at it, move the non-standard subtype and version fields into
> the WMM structs, to avoid this confusion in the future about generic
> "vendor header" attributes.
>
> Fixes: 685c9b7750bf ("mwifiex: Abort at too short BSS descriptor element")
> Cc: Takashi Iwai <tiwai@suse.de>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Reviewed-by: Takashi Iwai <tiwai@suse.de>
Patch applied to wireless-drivers.git, thanks.
63d7ef36103d mwifiex: Don't abort on small, spec-compliant vendor IEs
--
https://patchwork.kernel.org/patch/10996895/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] iwlwifi: add support for hr1 RF ID
From: Kalle Valo @ 2019-06-24 13:24 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Oren Givon, stable, Luciano Coelho
In-Reply-To: <20190620084623.12014-1-luca@coelho.fi>
Luca Coelho <luca@coelho.fi> wrote:
> From: Oren Givon <oren.givon@intel.com>
>
> The 22000 series FW that was meant to be used with hr is
> also the FW that is used for hr1 and has a different RF ID.
> Add support to load the hr FW when hr1 RF ID is detected.
>
> Cc: stable@vger.kernel.org # 5.1+
> Signed-off-by: Oren Givon <oren.givon@intel.com>
> Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Patch applied to wireless-drivers.git, thanks.
498d3eb5bfbb iwlwifi: add support for hr1 RF ID
--
https://patchwork.kernel.org/patch/11006135/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in p54u_load_firmware_cb
From: Kalle Valo @ 2019-06-24 13:24 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Christian Lamparter, Alan Stern, syzbot, Christian Lamparter,
David S. Miller, Kernel development list, USB list,
linux-wireless, netdev, syzkaller-bugs
In-Reply-To: <CAAeHK+zhcgmBQT=rdHaCMu7XWPz4o1gwzCJQEXiTEW9_iUUauA@mail.gmail.com>
Andrey Konovalov <andreyknvl@google.com> writes:
> On Thu, Jun 20, 2019 at 9:56 PM Christian Lamparter <chunkeey@gmail.com> wrote:
>>
>> 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/>
>
> Yes, until this patch is in the tree that is being tested (which is
> based on the usb-linus branch; I update it every few weeks), syzbot
> considers this bug as open.
I'm hoping to apply this today or tomorrow.
--
Kalle Valo
^ permalink raw reply
* Re: [RESEND] brcmfmac support for BCM4359 sdio on arm64 ??
From: Christian Hewitt @ 2019-06-24 15:45 UTC (permalink / raw)
To: Arend Van Spriel
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
Wright.Feng, Neil Armstrong, Christoph Muellner
In-Reply-To: <37d2964d-1c2b-51bd-ac98-2cc171aa0c9c@broadcom.com>
On 11 Jun 2019, at 1:45 pm, Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
>
> The splat could be relevant. Maybe try the patch below to get actual values that are checked in the WARN_ON.
>
>> BCMDHD is also reported working with commits here: https://gitlab.com/baylibre/amlogic/atv/linux/commits/narmstrong/v5.1/aml/integ-5.1-bcmdhd but LibreELEC needs to support many different boards (with many different SDIO modules) from a single OS image, so BCMDHD is not the solution we need.
>> One additional patch I spotted mentioning BCM4359 (also from Wright Feng) was https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/65f17112e1c883d3c9f3fa68837e5f9b5eb7cfad/patches/cypress/v4.14.52-2018_0928/cypress-patch/0073-non-upstream-reset-two-D11-cores-if-chip-has-two-D11.patch but it makes no difference (the dmesg log above is with this patch applied).
>> I don’t write code but am happy to build test kernels with suggested patches or explicit instructions. I’ve also CC’d LibreELEC colleague and linux-amlogic maintainer Neil Armstrong who can assist. NB: If direct access to hardware would help progress things I can easily organise remote access or get board samples shipped.
>> How can we resume the investigation?
>
> Let's try one step at a time ;-)
>
> Regards,
> Arend
> ---
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/driver
> index fc12598..e9b0986 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -772,7 +772,8 @@ void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev *sdiod
> sdiodev->settings->bus.sdio.txglomsz);
> nents += (nents >> 4) + 1;
>
> - WARN_ON(nents > sdiodev->max_segment_count);
> + WARN(nents > sdiodev->max_segment_count, "max_seg_cnt=%u, host_max_seg=
> + sdiodev->max_segment_count, host->max_segs, nents);
>
> brcmf_dbg(TRACE, "nents=%d\n", nents);
> err = sg_alloc_table(&sdiodev->sgtable, nents, GFP_KERNEL);
> q
^ this patch is mangled - please send me the correct one so I can reply with information to move things forwards. Thanks.
Christian
^ 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