* Re: [PATCH v3 2/5] mdev: Make mdev alias unique among all mdevs
From: Cornelia Huck @ 2019-09-17 10:04 UTC (permalink / raw)
To: Parav Pandit
Cc: alex.williamson, jiri, kwankhede, davem, kvm, linux-kernel,
netdev
In-Reply-To: <20190902042436.23294-3-parav@mellanox.com>
On Sun, 1 Sep 2019 23:24:33 -0500
Parav Pandit <parav@mellanox.com> wrote:
> Mdev alias should be unique among all the mdevs, so that when such alias
> is used by the mdev users to derive other objects, there is no
> collision in a given system.
>
> Signed-off-by: Parav Pandit <parav@mellanox.com>
>
> ---
> Changelog:
> v2->v3:
> - Changed strcmp() ==0 to !strcmp()
> v1->v2:
> - Moved alias NULL check at beginning
> v0->v1:
> - Fixed inclusiong of alias for NULL check
> - Added ratelimited debug print for sha1 hash collision error
> ---
> drivers/vfio/mdev/mdev_core.c | 7 +++++++
> 1 file changed, 7 insertions(+)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* Re: [PATCH v3 1/5] mdev: Introduce sha1 based mdev alias
From: Cornelia Huck @ 2019-09-17 10:03 UTC (permalink / raw)
To: Parav Pandit
Cc: alex.williamson, jiri, kwankhede, davem, kvm, linux-kernel,
netdev
In-Reply-To: <20190902042436.23294-2-parav@mellanox.com>
On Sun, 1 Sep 2019 23:24:32 -0500
Parav Pandit <parav@mellanox.com> wrote:
> Some vendor drivers want an identifier for an mdev device that is
> shorter than the UUID, due to length restrictions in the consumers of
> that identifier.
>
> Add a callback that allows a vendor driver to request an alias of a
> specified length to be generated for an mdev device. If generated,
> that alias is checked for collisions.
>
> It is an optional attribute.
> mdev alias is generated using sha1 from the mdev name.
>
> Signed-off-by: Parav Pandit <parav@mellanox.com>
>
> ---
> Changelog:
> v1->v2:
> - Kept mdev_device naturally aligned
> - Added error checking for crypt_*() calls
> - Corrected a typo from 'and' to 'an'
> - Changed return type of generate_alias() from int to char*
> v0->v1:
> - Moved alias length check outside of the parent lock
> - Moved alias and digest allocation from kvzalloc to kzalloc
> - &alias[0] changed to alias
> - alias_length check is nested under get_alias_length callback check
> - Changed comments to start with an empty line
> - Fixed cleaunup of hash if mdev_bus_register() fails
> - Added comment where alias memory ownership is handed over to mdev device
> - Updated commit log to indicate motivation for this feature
> ---
> drivers/vfio/mdev/mdev_core.c | 123 ++++++++++++++++++++++++++++++-
> drivers/vfio/mdev/mdev_private.h | 5 +-
> drivers/vfio/mdev/mdev_sysfs.c | 13 ++--
> include/linux/mdev.h | 4 +
> 4 files changed, 135 insertions(+), 10 deletions(-)
(...)
> diff --git a/include/linux/mdev.h b/include/linux/mdev.h
> index 0ce30ca78db0..f036fe9854ee 100644
> --- a/include/linux/mdev.h
> +++ b/include/linux/mdev.h
> @@ -72,6 +72,9 @@ struct device *mdev_get_iommu_device(struct device *dev);
> * @mmap: mmap callback
> * @mdev: mediated device structure
> * @vma: vma structure
> + * @get_alias_length: Generate alias for the mdevs of this parent based on the
> + * mdev device name when it returns non zero alias length.
"Optional: If a non-zero alias length is returned, generate an alias
for this parent's mdevs based upon the mdev device name."
?
> + * It is optional.
> * Parent device that support mediated device should be registered with mdev
> * module with mdev_parent_ops structure.
> **/
> @@ -92,6 +95,7 @@ struct mdev_parent_ops {
> long (*ioctl)(struct mdev_device *mdev, unsigned int cmd,
> unsigned long arg);
> int (*mmap)(struct mdev_device *mdev, struct vm_area_struct *vma);
> + unsigned int (*get_alias_length)(void);
> };
>
> /* interface for exporting mdev supported type attributes */
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* [PATCH] net: stmmac: Fix ASSERT_RTNL() warning on suspend/resume
From: Loys Ollivier @ 2019-09-17 10:02 UTC (permalink / raw)
To: Russell King, Maxime Coquelin
Cc: Loys Ollivier, Jose Abreu, David S. Miller, Giuseppe Cavallaro,
Alexandre Torgue, netdev, linux-stm32, linux-arm-kernel,
linux-kernel
rtnl_lock needs to be taken before calling phylink_start/stop to lock the
network stack.
Fix ASSERT_RTNL() warnings by protecting such calls with lock/unlock.
Fixes: 74371272f97f ("net: stmmac: Convert to phylink and remove phylib logic")
Signed-off-by: Loys Ollivier <lollivier@baylibre.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index fd54c7c87485..485f33f57b43 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4451,7 +4451,9 @@ int stmmac_suspend(struct device *dev)
if (!ndev || !netif_running(ndev))
return 0;
+ rtnl_lock();
phylink_stop(priv->phylink);
+ rtnl_unlock();
mutex_lock(&priv->lock);
@@ -4560,7 +4562,9 @@ int stmmac_resume(struct device *dev)
mutex_unlock(&priv->lock);
+ rtnl_lock();
phylink_start(priv->phylink);
+ rtnl_unlock();
return 0;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] ixgbe: Use memset_explicit directly in crypto cases
From: Sergei Shtylyov @ 2019-09-17 9:59 UTC (permalink / raw)
To: zhong jiang, jakub.kicinski, davem
Cc: anna.schumaker, trond.myklebust, netdev, linux-kernel
In-Reply-To: <1568691910-21442-1-git-send-email-zhongjiang@huawei.com>
Hello!
On 17.09.2019 6:45, zhong jiang wrote:
> It's better to use memset_explicit() to replace memset() in crypto cases.
But you're using memzero_explicit() below?
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> index 31629fc..7e4f32f 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> @@ -960,10 +960,10 @@ int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
> return 0;
>
> err_aead:
> - memset(xs->aead, 0, sizeof(*xs->aead));
> + memzero_explicit(xs->aead, sizeof(*xs->aead));
> kfree(xs->aead);
> err_xs:
> - memset(xs, 0, sizeof(*xs));
> + memzero_explicit(xs, sizeof(*xs));
> kfree(xs);
> err_out:
> msgbuf[1] = err;
> @@ -1049,7 +1049,7 @@ int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
> ixgbe_ipsec_del_sa(xs);
>
> /* remove the xs that was made-up in the add request */
> - memset(xs, 0, sizeof(*xs));
> + memzero_explicit(xs, sizeof(*xs));
> kfree(xs);
>
> return 0;
MBR, Sergei
^ permalink raw reply
* Re: memory leak in cfserl_create
From: syzbot @ 2019-09-17 9:43 UTC (permalink / raw)
To: alexios.zavras, allison, davem, linux-kernel, netdev, rfontana,
swinslow, syzkaller-bugs, tglx
In-Reply-To: <00000000000053d7e9058a97f4ca@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: cef72982 Merge tag 'armsoc-dt' of git://git.kernel.org/pub..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1042ac45600000
kernel config: https://syzkaller.appspot.com/x/.config?x=779aef2b86e19d75
dashboard link: https://syzkaller.appspot.com/bug?extid=7ec324747ce876a29db6
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16ef2331600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f0c091600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7ec324747ce876a29db6@syzkaller.appspotmail.com
BUG: memory leak
unreferenced object 0xffff88810a3b7380 (size 128):
comm "syz-executor868", pid 7100, jiffies 4294943513 (age 21.740s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000004f492e65>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000004f492e65>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000004f492e65>] slab_alloc mm/slab.c:3319 [inline]
[<000000004f492e65>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000478a63c3>] kmalloc include/linux/slab.h:552 [inline]
[<00000000478a63c3>] kzalloc include/linux/slab.h:748 [inline]
[<00000000478a63c3>] cfserl_create+0x24/0x76 net/caif/cfserl.c:36
[<0000000097ca7138>] caif_device_notify+0x347/0x3bc
net/caif/caif_dev.c:388
[<0000000078bf2b15>] notifier_call_chain+0x66/0xb0 kernel/notifier.c:95
[<000000001a557d7e>] __raw_notifier_call_chain kernel/notifier.c:396
[inline]
[<000000001a557d7e>] raw_notifier_call_chain+0x2e/0x40
kernel/notifier.c:403
[<00000000de93bbde>] call_netdevice_notifiers_info+0x33/0x70
net/core/dev.c:1749
[<0000000004467db0>] call_netdevice_notifiers_extack
net/core/dev.c:1761 [inline]
[<0000000004467db0>] call_netdevice_notifiers net/core/dev.c:1775
[inline]
[<0000000004467db0>] register_netdevice+0x445/0x610 net/core/dev.c:8757
[<000000007e97ac10>] ldisc_open+0x1f7/0x350
drivers/net/caif/caif_serial.c:359
[<000000003eb33d8f>] tty_ldisc_open.isra.0+0x44/0x70
drivers/tty/tty_ldisc.c:469
[<00000000ded1208b>] tty_set_ldisc+0x149/0x240
drivers/tty/tty_ldisc.c:596
[<00000000df974937>] tiocsetd drivers/tty/tty_io.c:2334 [inline]
[<00000000df974937>] tty_ioctl+0x366/0xa30 drivers/tty/tty_io.c:2594
[<00000000739f048c>] vfs_ioctl fs/ioctl.c:46 [inline]
[<00000000739f048c>] file_ioctl fs/ioctl.c:509 [inline]
[<00000000739f048c>] do_vfs_ioctl+0x62a/0x810 fs/ioctl.c:696
[<00000000e122cb0c>] ksys_ioctl+0x86/0xb0 fs/ioctl.c:713
[<0000000067a2ba29>] __do_sys_ioctl fs/ioctl.c:720 [inline]
[<0000000067a2ba29>] __se_sys_ioctl fs/ioctl.c:718 [inline]
[<0000000067a2ba29>] __x64_sys_ioctl+0x1e/0x30 fs/ioctl.c:718
[<0000000071a2e1c5>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<00000000c342e2c0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810a3b7400 (size 128):
comm "syz-executor868", pid 7101, jiffies 4294943519 (age 21.680s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000004f492e65>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000004f492e65>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000004f492e65>] slab_alloc mm/slab.c:3319 [inline]
[<000000004f492e65>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000478a63c3>] kmalloc include/linux/slab.h:552 [inline]
[<00000000478a63c3>] kzalloc include/linux/slab.h:748 [inline]
[<00000000478a63c3>] cfserl_create+0x24/0x76 net/caif/cfserl.c:36
[<0000000097ca7138>] caif_device_notify+0x347/0x3bc
net/caif/caif_dev.c:388
[<0000000078bf2b15>] notifier_call_chain+0x66/0xb0 kernel/notifier.c:95
[<000000001a557d7e>] __raw_notifier_call_chain kernel/notifier.c:396
[inline]
[<000000001a557d7e>] raw_notifier_call_chain+0x2e/0x40
kernel/notifier.c:403
[<00000000de93bbde>] call_netdevice_notifiers_info+0x33/0x70
net/core/dev.c:1749
[<0000000004467db0>] call_netdevice_notifiers_extack
net/core/dev.c:1761 [inline]
[<0000000004467db0>] call_netdevice_notifiers net/core/dev.c:1775
[inline]
[<0000000004467db0>] register_netdevice+0x445/0x610 net/core/dev.c:8757
[<000000007e97ac10>] ldisc_open+0x1f7/0x350
drivers/net/caif/caif_serial.c:359
[<000000003eb33d8f>] tty_ldisc_open.isra.0+0x44/0x70
drivers/tty/tty_ldisc.c:469
[<00000000ded1208b>] tty_set_ldisc+0x149/0x240
drivers/tty/tty_ldisc.c:596
[<00000000df974937>] tiocsetd drivers/tty/tty_io.c:2334 [inline]
[<00000000df974937>] tty_ioctl+0x366/0xa30 drivers/tty/tty_io.c:2594
[<00000000739f048c>] vfs_ioctl fs/ioctl.c:46 [inline]
[<00000000739f048c>] file_ioctl fs/ioctl.c:509 [inline]
[<00000000739f048c>] do_vfs_ioctl+0x62a/0x810 fs/ioctl.c:696
[<00000000e122cb0c>] ksys_ioctl+0x86/0xb0 fs/ioctl.c:713
[<0000000067a2ba29>] __do_sys_ioctl fs/ioctl.c:720 [inline]
[<0000000067a2ba29>] __se_sys_ioctl fs/ioctl.c:718 [inline]
[<0000000067a2ba29>] __x64_sys_ioctl+0x1e/0x30 fs/ioctl.c:718
[<0000000071a2e1c5>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<00000000c342e2c0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810a3b7780 (size 128):
comm "syz-executor868", pid 7138, jiffies 4294943524 (age 21.630s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000004f492e65>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000004f492e65>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000004f492e65>] slab_alloc mm/slab.c:3319 [inline]
[<000000004f492e65>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000478a63c3>] kmalloc include/linux/slab.h:552 [inline]
[<00000000478a63c3>] kzalloc include/linux/slab.h:748 [inline]
[<00000000478a63c3>] cfserl_create+0x24/0x76 net/caif/cfserl.c:36
[<0000000097ca7138>] caif_device_notify+0x347/0x3bc
net/caif/caif_dev.c:388
[<0000000078bf2b15>] notifier_call_chain+0x66/0xb0 kernel/notifier.c:95
[<000000001a557d7e>] __raw_notifier_call_chain kernel/notifier.c:396
[inline]
[<000000001a557d7e>] raw_notifier_call_chain+0x2e/0x40
kernel/notifier.c:403
[<00000000de93bbde>] call_netdevice_notifiers_info+0x33/0x70
net/core/dev.c:1749
[<0000000004467db0>] call_netdevice_notifiers_extack
net/core/dev.c:1761 [inline]
[<0000000004467db0>] call_netdevice_notifiers net/core/dev.c:1775
[inline]
[<0000000004467db0>] register_netdevice+0x445/0x610 net/core/dev.c:8757
[<000000007e97ac10>] ldisc_open+0x1f7/0x350
drivers/net/caif/caif_serial.c:359
[<000000003eb33d8f>] tty_ldisc_open.isra.0+0x44/0x70
drivers/tty/tty_ldisc.c:469
[<00000000ded1208b>] tty_set_ldisc+0x149/0x240
drivers/tty/tty_ldisc.c:596
[<00000000df974937>] tiocsetd drivers/tty/tty_io.c:2334 [inline]
[<00000000df974937>] tty_ioctl+0x366/0xa30 drivers/tty/tty_io.c:2594
[<00000000739f048c>] vfs_ioctl fs/ioctl.c:46 [inline]
[<00000000739f048c>] file_ioctl fs/ioctl.c:509 [inline]
[<00000000739f048c>] do_vfs_ioctl+0x62a/0x810 fs/ioctl.c:696
[<00000000e122cb0c>] ksys_ioctl+0x86/0xb0 fs/ioctl.c:713
[<0000000067a2ba29>] __do_sys_ioctl fs/ioctl.c:720 [inline]
[<0000000067a2ba29>] __se_sys_ioctl fs/ioctl.c:718 [inline]
[<0000000067a2ba29>] __x64_sys_ioctl+0x1e/0x30 fs/ioctl.c:718
[<0000000071a2e1c5>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<00000000c342e2c0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
executing program
executing program
executing program
executing program
^ permalink raw reply
* [PATCH net] net/sched: act_sample: don't push mac header on ip6gre ingress
From: Davide Caratti @ 2019-09-17 9:30 UTC (permalink / raw)
To: Jiri Pirko, Cong Wang, Jamal Hadi Salim, David S. Miller, netdev
Cc: Yotam Gigi
current 'sample' action doesn't push the mac header of ingress packets if
they are received by a layer 3 tunnel (like gre or sit); but it forgot to
check for gre over ipv6, so the following script:
# tc q a dev $d clsact
# tc f a dev $d ingress protocol ip flower ip_proto icmp action sample \
> group 100 rate 1
# psample -v -g 100
dumps everything, including outer header and mac, when $d is a gre tunnel
over ipv6. Fix this adding a missing label for ARPHRD_IP6GRE devices.
Fixes: 5c5670fae430 ("net/sched: Introduce sample tc action")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/act_sample.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/sched/act_sample.c b/net/sched/act_sample.c
index 10229124a992..86344fd2ff1f 100644
--- a/net/sched/act_sample.c
+++ b/net/sched/act_sample.c
@@ -146,6 +146,7 @@ static bool tcf_sample_dev_ok_push(struct net_device *dev)
case ARPHRD_TUNNEL6:
case ARPHRD_SIT:
case ARPHRD_IPGRE:
+ case ARPHRD_IP6GRE:
case ARPHRD_VOID:
case ARPHRD_NONE:
return false;
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Jes Sorensen @ 2019-09-17 9:19 UTC (permalink / raw)
To: Chris Chiu, kvalo, davem
Cc: linux-wireless, netdev, linux-kernel, linux, Daniel Drake
In-Reply-To: <20190917074007.92259-1-chiu@endlessm.com>
On 9/17/19 3:40 AM, Chris Chiu wrote:
> We have 3 laptops which connect the wifi by the same RTL8723BU.
> The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
> They have the same problem with the in-kernel rtl8xxxu driver, the
> iperf (as a client to an ethernet-connected server) gets ~1Mbps.
> Nevertheless, the signal strength is reported as around -40dBm,
> which is quite good. From the wireshark capture, the tx rate for each
> data and qos data packet is only 1Mbps. Compare to the Realtek driver
> at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
> ~12Mbps or better. The signal strength is reported similarly around
> -40dBm. That's why we want to improve.
>
> After reading the source code of the rtl8xxxu driver and Realtek's, the
> major difference is that Realtek's driver has a watchdog which will keep
> monitoring the signal quality and updating the rate mask just like the
> rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
> And this kind of watchdog also exists in rtlwifi driver of some specific
> chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
> the same member function named dm_watchdog and will invoke the
> corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
> mask.
>
> With this commit, the tx rate of each data and qos data packet will
> be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit
> to 23th bit means MCS4 to MCS7. It means that the firmware still picks
> the lowest rate from the rate mask and explains why the tx rate of
> data and qos data is always lowest 1Mbps because the default rate mask
> passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate,
> and MCS rate. However, with Realtek's driver, the tx rate observed from
> wireshark under the same condition is almost 65Mbps or 72Mbps, which
> indicating that rtl8xxxu could still be further improved.
>
> Signed-off-by: Chris Chiu <chiu@endlessm.com>
> Reviewed-by: Daniel Drake <drake@endlessm.com>
I am still traveling after Plumbers and don't have my 8723bu dongles
with me, but I'd say this looks good.
Acked-by: Jes Sorensen <Jes.Sorensen@gmail.com>
Jes
^ permalink raw reply
* Re: [PATCHv2 ipsec-next] xfrm: remove the unnecessary .net_exit for xfrmi
From: Steffen Klassert @ 2019-09-17 9:02 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem
In-Reply-To: <0e9b72a6caf695dd99c02bd223168897977daaef.1568017810.git.lucien.xin@gmail.com>
On Mon, Sep 09, 2019 at 04:30:10PM +0800, Xin Long wrote:
> The xfrm_if(s) on each netns can be deleted when its xfrmi dev is
> deleted. xfrmi dev's removal can happen when:
>
> a. netns is being removed and all xfrmi devs will be deleted.
>
> b. rtnl_link_unregister(&xfrmi_link_ops) in xfrmi_fini() when
> xfrm_interface.ko is being unloaded.
>
> So there's no need to use xfrmi_exit_net() to clean any xfrm_if up.
>
> v1->v2:
> - Fix some changelog.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
I've queued this for applying until after the merge window,
no need to resend.
Thanks!
^ permalink raw reply
* Re: BUG: sleeping function called from invalid context in tcf_chain0_head_change_cb_del
From: Vlad Buslov @ 2019-09-17 8:27 UTC (permalink / raw)
To: Cong Wang
Cc: syzbot, Alexei Starovoitov, Daniel Borkmann, David Miller,
David Ahern, Florian Fainelli, hawk@kernel.org, Ido Schimmel,
Jakub Kicinski, Jamal Hadi Salim, Jiri Pirko, Jiri Pirko,
John Fastabend, Martin KaFai Lau, LKML,
Linux Kernel Network Developers, Nikolay Aleksandrov,
Petr Machata, Roopa Prabhu, Song Liu, syzkaller-bugs, Vlad Buslov,
xdp-newbies@vger.kernel.org, yhs@fb.com
In-Reply-To: <CAM_iQpX0FAvhcZgKjRd=3Rbp8cbfYiUqkF2KnmF9Pd0U4EkSDw@mail.gmail.com>
On Tue 17 Sep 2019 at 04:58, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Mon, Sep 16, 2019 at 4:39 PM syzbot
> <syzbot+ac54455281db908c581e@syzkaller.appspotmail.com> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: 1609d760 Merge tag 'for-linus' of git://git.kernel.org/pub..
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=10236abe600000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=ed2b148cd67382ec
>> dashboard link: https://syzkaller.appspot.com/bug?extid=ac54455281db908c581e
>> compiler: clang version 9.0.0 (/home/glider/llvm/clang
>> 80fee25776c2fb61e74c1ecb1a523375c2500b69)
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116c4b11600000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15ff270d600000
>>
>> The bug was bisected to:
>>
>> commit c266f64dbfa2a970a13b0574246c0ddfec492365
>> Author: Vlad Buslov <vladbu@mellanox.com>
>> Date: Mon Feb 11 08:55:32 2019 +0000
>>
>> net: sched: protect block state with mutex
>>
>> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16e7ca65600000
>> final crash: https://syzkaller.appspot.com/x/report.txt?x=15e7ca65600000
>> console output: https://syzkaller.appspot.com/x/log.txt?x=11e7ca65600000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+ac54455281db908c581e@syzkaller.appspotmail.com
>> Fixes: c266f64dbfa2 ("net: sched: protect block state with mutex")
>>
>> BUG: sleeping function called from invalid context at
>> kernel/locking/mutex.c:909
>> in_atomic(): 1, irqs_disabled(): 0, pid: 9297, name: syz-executor942
>> INFO: lockdep is turned off.
>> Preemption disabled at:
>> [<ffffffff8604de24>] spin_lock_bh include/linux/spinlock.h:343 [inline]
>> [<ffffffff8604de24>] sch_tree_lock include/net/sch_generic.h:570 [inline]
>> [<ffffffff8604de24>] sfb_change+0x284/0xd30 net/sched/sch_sfb.c:519
>> CPU: 0 PID: 9297 Comm: syz-executor942 Not tainted 5.3.0-rc8+ #0
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> __dump_stack lib/dump_stack.c:77 [inline]
>> dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
>> ___might_sleep+0x3ff/0x530 kernel/sched/core.c:6608
>> __might_sleep+0x8f/0x100 kernel/sched/core.c:6561
>> __mutex_lock_common+0x4e/0x2820 kernel/locking/mutex.c:909
>> __mutex_lock kernel/locking/mutex.c:1077 [inline]
>> mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1092
>> tcf_chain0_head_change_cb_del+0x30/0x390 net/sched/cls_api.c:932
>> tcf_block_put_ext+0x3d/0x2a0 net/sched/cls_api.c:1502
>> tcf_block_put+0x6e/0x90 net/sched/cls_api.c:1515
>> sfb_destroy+0x47/0x70 net/sched/sch_sfb.c:467
>> qdisc_destroy+0x147/0x4d0 net/sched/sch_generic.c:968
>> qdisc_put+0x58/0x90 net/sched/sch_generic.c:992
>> sfb_change+0x52d/0xd30 net/sched/sch_sfb.c:522
>
> I don't think we have to hold the qdisc tree lock when destroying
> the old qdisc. Does the following change make sense?
>
> diff --git a/net/sched/sch_sfb.c b/net/sched/sch_sfb.c
> index 1dff8506a715..726d0fa956b1 100644
> --- a/net/sched/sch_sfb.c
> +++ b/net/sched/sch_sfb.c
> @@ -488,7 +488,7 @@ static int sfb_change(struct Qdisc *sch, struct nlattr *opt,
> struct netlink_ext_ack *extack)
> {
> struct sfb_sched_data *q = qdisc_priv(sch);
> - struct Qdisc *child;
> + struct Qdisc *child, *tmp;
> struct nlattr *tb[TCA_SFB_MAX + 1];
> const struct tc_sfb_qopt *ctl = &sfb_default_ops;
> u32 limit;
> @@ -519,7 +519,7 @@ static int sfb_change(struct Qdisc *sch, struct nlattr *opt,
> sch_tree_lock(sch);
>
> qdisc_tree_flush_backlog(q->qdisc);
> - qdisc_put(q->qdisc);
> + tmp = q->qdisc;
> q->qdisc = child;
>
> q->rehash_interval = msecs_to_jiffies(ctl->rehash_interval);
> @@ -543,6 +543,7 @@ static int sfb_change(struct Qdisc *sch, struct nlattr *opt,
>
> sch_tree_unlock(sch);
>
> + qdisc_put(tmp);
> return 0;
> }
>
>
> What do you think, Vlad?
Hi Cong,
Don't see why we would need qdisc tree lock while releasing the
reference to (or destroying) previous Qdisc. I've skimmed through other
scheds and it looks like sch_multiq, sch_htb and sch_tbf are also
affected. Do you want me to send patches?
Regards,
Vlad
^ permalink raw reply
* Re: [PATCH] netfilter: bridge: drop a broken include
From: Jeremy Sowden @ 2019-09-17 8:08 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Adam Borowski, Jozsef Kadlecsik, Florian Westphal, Roopa Prabhu,
Nikolay Aleksandrov, netfilter-devel, coreteam, netdev
In-Reply-To: <20190917050946.kmzajvqh3kjr4ch5@salvia>
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
On 2019-09-17, at 07:09:46 +0200, Pablo Neira Ayuso wrote:
> On Mon, Sep 16, 2019 at 02:08:12PM +0100, Jeremy Sowden wrote:
> > On 2019-09-16, at 02:05:16 +0200, Adam Borowski wrote:
> > > This caused a build failure if CONFIG_NF_CONNTRACK_BRIDGE is set but
> > > CONFIG_NF_TABLES=n -- and appears to be unused anyway.
> [...]
> > There are already changes in the net-next tree that will fix it.
>
> If the fix needs to go to -stable 5.3 kernel release, then you have to
> point to the particular commit ID of this patch to fix this one.
> net-next contains 5.4-rc material. I'd appreciate also if you can help
> identify the patch with a Fixes: tag.
Yup, will do.
J.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: -Wsizeof-array-div warnings in ethernet drivers
From: Jose Abreu @ 2019-09-17 7:58 UTC (permalink / raw)
To: Nathan Chancellor, Tom Lendacky, Giuseppe Cavallaro,
Alexandre Torgue, David S. Miller
Cc: Nick Desaulniers, Ilie Halip, David Bolvansky,
netdev@vger.kernel.org, clang-built-linux@googlegroups.com
In-Reply-To: <20190917073232.GA14291@archlinux-threadripper>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Sep/17/2019, 08:32:32 (UTC+00:00)
> Hi all,
>
> Clang recently added a new diagnostic in r371605, -Wsizeof-array-div,
> that tries to warn when sizeof(X) / sizeof(Y) does not compute the
> number of elements in an array X (i.e., sizeof(Y) is wrong). See that
> commit for more details:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_llvm_llvm-2Dproject_commit_3240ad4ced0d3223149b72a4fc2a4d9b67589427&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=yaVFU4TjGY0gVF8El1uKcisy6TPsyCl9uN7Wsis-qhY&m=XFx3a9bS-B05voQh4LJquxHuP4TOowjC82tcMo4gPz0&s=NpzuPgHoSG2p4Mg6ko4MgHHV3TpTwEGm2XNTyw-s3XY&e=
>
> Some ethernet drivers have an instance of this warning due to receive
> side scaling support:
>
>
> ../drivers/net/ethernet/amd/xgbe/xgbe-dev.c:361:49: warning: expression
> does not compute the number of elements in this array; element type is
> 'u8' (aka 'unsigned char'), not 'u32' (aka 'unsigned int')
> [-Wsizeof-array-div]
> unsigned int key_regs = sizeof(pdata->rss_key) / sizeof(u32);
> ~~~~~~~~~~~~~~ ^
> ../drivers/net/ethernet/amd/xgbe/xgbe-dev.c:361:49: note: place
> parentheses around the 'sizeof(u32)' expression to silence this warning
>
>
> ../drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c:537:36: warning:
> expression does not compute the number of elements in this array;
> element type is 'u8' (aka 'unsigned char'), not 'u32' (aka 'unsigned
> int') [-Wsizeof-array-div]
> for (i = 0; i < (sizeof(cfg->key) / sizeof(u32)); i++) {
> ~~~~~~~~ ^
> ../drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c:537:36: note:
> place parentheses around the 'sizeof(u32)' expression to silence this
> warning
>
>
> ../drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c:2329:49: warning:
> expression does not compute the number of elements in this array;
> element type is 'u8' (aka 'unsigned char'), not 'u32' (aka 'unsigned
> int') [-Wsizeof-array-div]
> unsigned int key_regs = sizeof(pdata->rss_key) / sizeof(u32);
> ~~~~~~~~~~~~~~ ^
> ../drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c:2329:49: note: place
> parentheses around the 'sizeof(u32)' expression to silence this warning
>
>
> What is the reasoning behind having the key being an array of u8s but
> seemlingly converting it into an array of u32s? It's not immediately
> apparent from reading over the code but I am not familiar with it so I
> might be making a mistake. I assume this is intentional? If so, the
> warning can be silenced and we'll send patches to do so but we want to
> make sure we aren't actually papering over a mistake.
This is because we write 32 bits at a time to the reg but internally the
driver uses 8 bits to store the array. If you look at
dwxgmac2_rss_configure() you'll see that cfg->key is casted to u32 which
is the value we use in HW writes. Then the for loop just does the math
to check how many u32's has to write.
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* [PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Chris Chiu @ 2019-09-17 7:40 UTC (permalink / raw)
To: Jes.Sorensen, kvalo, davem
Cc: linux-wireless, netdev, linux-kernel, linux, Daniel Drake
We have 3 laptops which connect the wifi by the same RTL8723BU.
The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
They have the same problem with the in-kernel rtl8xxxu driver, the
iperf (as a client to an ethernet-connected server) gets ~1Mbps.
Nevertheless, the signal strength is reported as around -40dBm,
which is quite good. From the wireshark capture, the tx rate for each
data and qos data packet is only 1Mbps. Compare to the Realtek driver
at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
~12Mbps or better. The signal strength is reported similarly around
-40dBm. That's why we want to improve.
After reading the source code of the rtl8xxxu driver and Realtek's, the
major difference is that Realtek's driver has a watchdog which will keep
monitoring the signal quality and updating the rate mask just like the
rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
And this kind of watchdog also exists in rtlwifi driver of some specific
chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
the same member function named dm_watchdog and will invoke the
corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
mask.
With this commit, the tx rate of each data and qos data packet will
be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit
to 23th bit means MCS4 to MCS7. It means that the firmware still picks
the lowest rate from the rate mask and explains why the tx rate of
data and qos data is always lowest 1Mbps because the default rate mask
passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate,
and MCS rate. However, with Realtek's driver, the tx rate observed from
wireshark under the same condition is almost 65Mbps or 72Mbps, which
indicating that rtl8xxxu could still be further improved.
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Reviewed-by: Daniel Drake <drake@endlessm.com>
---
Notes:
v2:
- Fix errors and warnings complained by checkpatch.pl
- Replace data structure rate_adaptive by 2 member variables
- Make rtl8xxxu_wireless_mode non-static
- Runs refresh_rate_mask() only in station mode
v3:
- Remove ugly rtl8xxxu_watchdog data structure
- Make sure only one vif exists
v4:
- Move cancel_delayed_work from rtl8xxxu_disconnect to rtl8xxxu_stop
- Clear priv->vif in rtl8xxxu_remove_interface
- Add rateid as the function argument of update_rate_mask
- Rephrase the comment for priv->vif more explicit.
v5:
- Make refresh_rate_mask() generic for all sub-drivers.
- Add definitions for SNR related to help determine rssi_level
v6:
- Fix typo of the comment for priv->vif
v7:
- Fix reported bug of watchdog stop
- refer to the RxPWDBAll in vendor driver for SNR calculation
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 55 ++++-
.../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 229 +++++++++++++++++-
2 files changed, 277 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index ade057d868f7..582c2a346cec 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1187,6 +1187,48 @@ struct rtl8723bu_c2h {
struct rtl8xxxu_fileops;
+/*mlme related.*/
+enum wireless_mode {
+ WIRELESS_MODE_UNKNOWN = 0,
+ /* Sub-Element */
+ WIRELESS_MODE_B = BIT(0),
+ WIRELESS_MODE_G = BIT(1),
+ WIRELESS_MODE_A = BIT(2),
+ WIRELESS_MODE_N_24G = BIT(3),
+ WIRELESS_MODE_N_5G = BIT(4),
+ WIRELESS_AUTO = BIT(5),
+ WIRELESS_MODE_AC = BIT(6),
+ WIRELESS_MODE_MAX = 0x7F,
+};
+
+/* from rtlwifi/wifi.h */
+enum ratr_table_mode_new {
+ RATEID_IDX_BGN_40M_2SS = 0,
+ RATEID_IDX_BGN_40M_1SS = 1,
+ RATEID_IDX_BGN_20M_2SS_BN = 2,
+ RATEID_IDX_BGN_20M_1SS_BN = 3,
+ RATEID_IDX_GN_N2SS = 4,
+ RATEID_IDX_GN_N1SS = 5,
+ RATEID_IDX_BG = 6,
+ RATEID_IDX_G = 7,
+ RATEID_IDX_B = 8,
+ RATEID_IDX_VHT_2SS = 9,
+ RATEID_IDX_VHT_1SS = 10,
+ RATEID_IDX_MIX1 = 11,
+ RATEID_IDX_MIX2 = 12,
+ RATEID_IDX_VHT_3SS = 13,
+ RATEID_IDX_BGN_3SS = 14,
+};
+
+#define RTL8XXXU_RATR_STA_INIT 0
+#define RTL8XXXU_RATR_STA_HIGH 1
+#define RTL8XXXU_RATR_STA_MID 2
+#define RTL8XXXU_RATR_STA_LOW 3
+
+#define RTL8XXXU_NOISE_FLOOR_MIN -100
+#define RTL8XXXU_SNR_THRESH_HIGH 50
+#define RTL8XXXU_SNR_THRESH_LOW 20
+
struct rtl8xxxu_priv {
struct ieee80211_hw *hw;
struct usb_device *udev;
@@ -1291,6 +1333,13 @@ struct rtl8xxxu_priv {
u8 pi_enabled:1;
u8 no_pape:1;
u8 int_buf[USB_INTR_CONTENT_LENGTH];
+ u8 rssi_level;
+ /*
+ * Only one virtual interface permitted because only STA mode
+ * is supported and no iface_combinations are provided.
+ */
+ struct ieee80211_vif *vif;
+ struct delayed_work ra_watchdog;
};
struct rtl8xxxu_rx_urb {
@@ -1326,7 +1375,7 @@ struct rtl8xxxu_fileops {
void (*set_tx_power) (struct rtl8xxxu_priv *priv, int channel,
bool ht40);
void (*update_rate_mask) (struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void (*report_connect) (struct rtl8xxxu_priv *priv,
u8 macid, bool connect);
void (*fill_txdesc) (struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
@@ -1411,9 +1460,9 @@ void rtl8xxxu_gen2_config_channel(struct ieee80211_hw *hw);
void rtl8xxxu_gen1_usb_quirks(struct rtl8xxxu_priv *priv);
void rtl8xxxu_gen2_usb_quirks(struct rtl8xxxu_priv *priv);
void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi);
+ u32 ramask, u8 rateid, int sgi);
void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv *priv,
u8 macid, bool connect);
void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index c6c41fb962ff..a6f358b9e447 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4304,7 +4304,8 @@ static void rtl8xxxu_sw_scan_complete(struct ieee80211_hw *hw,
rtl8xxxu_write8(priv, REG_BEACON_CTRL, val8);
}
-void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv, u32 ramask, int sgi)
+void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv,
+ u32 ramask, u8 rateid, int sgi)
{
struct h2c_cmd h2c;
@@ -4324,7 +4325,7 @@ void rtl8xxxu_update_rate_mask(struct rtl8xxxu_priv *priv, u32 ramask, int sgi)
}
void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
- u32 ramask, int sgi)
+ u32 ramask, u8 rateid, int sgi)
{
struct h2c_cmd h2c;
u8 bw = 0;
@@ -4338,7 +4339,7 @@ void rtl8xxxu_gen2_update_rate_mask(struct rtl8xxxu_priv *priv,
h2c.b_macid_cfg.ramask3 = (ramask >> 24) & 0xff;
h2c.ramask.arg = 0x80;
- h2c.b_macid_cfg.data1 = 0;
+ h2c.b_macid_cfg.data1 = rateid;
if (sgi)
h2c.b_macid_cfg.data1 |= BIT(7);
@@ -4478,6 +4479,40 @@ static void rtl8xxxu_set_basic_rates(struct rtl8xxxu_priv *priv, u32 rate_cfg)
rtl8xxxu_write8(priv, REG_INIRTS_RATE_SEL, rate_idx);
}
+static u16
+rtl8xxxu_wireless_mode(struct ieee80211_hw *hw, struct ieee80211_sta *sta)
+{
+ u16 network_type = WIRELESS_MODE_UNKNOWN;
+ u32 rate_mask;
+
+ rate_mask = (sta->supp_rates[0] & 0xfff) |
+ (sta->ht_cap.mcs.rx_mask[0] << 12) |
+ (sta->ht_cap.mcs.rx_mask[0] << 20);
+
+ if (hw->conf.chandef.chan->band == NL80211_BAND_5GHZ) {
+ if (sta->vht_cap.vht_supported)
+ network_type = WIRELESS_MODE_AC;
+ else if (sta->ht_cap.ht_supported)
+ network_type = WIRELESS_MODE_N_5G;
+
+ network_type |= WIRELESS_MODE_A;
+ } else {
+ if (sta->vht_cap.vht_supported)
+ network_type = WIRELESS_MODE_AC;
+ else if (sta->ht_cap.ht_supported)
+ network_type = WIRELESS_MODE_N_24G;
+
+ if (sta->supp_rates[0] <= 0xf)
+ network_type |= WIRELESS_MODE_B;
+ else if (sta->supp_rates[0] & 0xf)
+ network_type |= (WIRELESS_MODE_B | WIRELESS_MODE_G);
+ else
+ network_type |= WIRELESS_MODE_G;
+ }
+
+ return network_type;
+}
+
static void
rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ieee80211_bss_conf *bss_conf, u32 changed)
@@ -4520,7 +4555,10 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
sgi = 1;
rcu_read_unlock();
- priv->fops->update_rate_mask(priv, ramask, sgi);
+ priv->vif = vif;
+ priv->rssi_level = RTL8XXXU_RATR_STA_INIT;
+
+ priv->fops->update_rate_mask(priv, ramask, 0, sgi);
rtl8xxxu_write8(priv, REG_BCN_MAX_ERR, 0xff);
@@ -5464,6 +5502,10 @@ static int rtl8xxxu_add_interface(struct ieee80211_hw *hw,
switch (vif->type) {
case NL80211_IFTYPE_STATION:
+ if (!priv->vif)
+ priv->vif = vif;
+ else
+ return -EOPNOTSUPP;
rtl8xxxu_stop_tx_beacon(priv);
val8 = rtl8xxxu_read8(priv, REG_BEACON_CTRL);
@@ -5487,6 +5529,9 @@ static void rtl8xxxu_remove_interface(struct ieee80211_hw *hw,
struct rtl8xxxu_priv *priv = hw->priv;
dev_dbg(&priv->udev->dev, "%s\n", __func__);
+
+ if (priv->vif)
+ priv->vif = NULL;
}
static int rtl8xxxu_config(struct ieee80211_hw *hw, u32 changed)
@@ -5772,6 +5817,177 @@ rtl8xxxu_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
return 0;
}
+static u8 rtl8xxxu_signal_to_snr(int signal)
+{
+ if (signal < RTL8XXXU_NOISE_FLOOR_MIN)
+ signal = RTL8XXXU_NOISE_FLOOR_MIN;
+ else if (signal > 0)
+ signal = 0;
+ return (u8)(signal - RTL8XXXU_NOISE_FLOOR_MIN);
+}
+
+static void rtl8xxxu_refresh_rate_mask(struct rtl8xxxu_priv *priv,
+ int signal, struct ieee80211_sta *sta)
+{
+ struct ieee80211_hw *hw = priv->hw;
+ u16 wireless_mode;
+ u8 rssi_level, ratr_idx;
+ u8 txbw_40mhz;
+ u8 snr, snr_thresh_high, snr_thresh_low;
+ u8 go_up_gap = 5;
+
+ rssi_level = priv->rssi_level;
+ snr = rtl8xxxu_signal_to_snr(signal);
+ snr_thresh_high = RTL8XXXU_SNR_THRESH_HIGH;
+ snr_thresh_low = RTL8XXXU_SNR_THRESH_LOW;
+ txbw_40mhz = (hw->conf.chandef.width == NL80211_CHAN_WIDTH_40) ? 1 : 0;
+
+ switch (rssi_level) {
+ case RTL8XXXU_RATR_STA_MID:
+ snr_thresh_high += go_up_gap;
+ break;
+ case RTL8XXXU_RATR_STA_LOW:
+ snr_thresh_high += go_up_gap;
+ snr_thresh_low += go_up_gap;
+ break;
+ default:
+ break;
+ }
+
+ if (snr > snr_thresh_high)
+ rssi_level = RTL8XXXU_RATR_STA_HIGH;
+ else if (snr > snr_thresh_low)
+ rssi_level = RTL8XXXU_RATR_STA_MID;
+ else
+ rssi_level = RTL8XXXU_RATR_STA_LOW;
+
+ if (rssi_level != priv->rssi_level) {
+ int sgi = 0;
+ u32 rate_bitmap = 0;
+
+ rcu_read_lock();
+ rate_bitmap = (sta->supp_rates[0] & 0xfff) |
+ (sta->ht_cap.mcs.rx_mask[0] << 12) |
+ (sta->ht_cap.mcs.rx_mask[1] << 20);
+ if (sta->ht_cap.cap &
+ (IEEE80211_HT_CAP_SGI_40 | IEEE80211_HT_CAP_SGI_20))
+ sgi = 1;
+ rcu_read_unlock();
+
+ wireless_mode = rtl8xxxu_wireless_mode(hw, sta);
+ switch (wireless_mode) {
+ case WIRELESS_MODE_B:
+ ratr_idx = RATEID_IDX_B;
+ if (rate_bitmap & 0x0000000c)
+ rate_bitmap &= 0x0000000d;
+ else
+ rate_bitmap &= 0x0000000f;
+ break;
+ case WIRELESS_MODE_A:
+ case WIRELESS_MODE_G:
+ ratr_idx = RATEID_IDX_G;
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
+ rate_bitmap &= 0x00000f00;
+ else
+ rate_bitmap &= 0x00000ff0;
+ break;
+ case (WIRELESS_MODE_B | WIRELESS_MODE_G):
+ ratr_idx = RATEID_IDX_BG;
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH)
+ rate_bitmap &= 0x00000f00;
+ else if (rssi_level == RTL8XXXU_RATR_STA_MID)
+ rate_bitmap &= 0x00000ff0;
+ else
+ rate_bitmap &= 0x00000ff5;
+ break;
+ case WIRELESS_MODE_N_24G:
+ case WIRELESS_MODE_N_5G:
+ case (WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
+ case (WIRELESS_MODE_A | WIRELESS_MODE_N_5G):
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_GN_N2SS;
+ else
+ ratr_idx = RATEID_IDX_GN_N1SS;
+ case (WIRELESS_MODE_B | WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
+ case (WIRELESS_MODE_B | WIRELESS_MODE_N_24G):
+ if (txbw_40mhz) {
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_BGN_40M_2SS;
+ else
+ ratr_idx = RATEID_IDX_BGN_40M_1SS;
+ } else {
+ if (priv->tx_paths == 2 && priv->rx_paths == 2)
+ ratr_idx = RATEID_IDX_BGN_20M_2SS_BN;
+ else
+ ratr_idx = RATEID_IDX_BGN_20M_1SS_BN;
+ }
+
+ if (priv->tx_paths == 2 && priv->rx_paths == 2) {
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
+ rate_bitmap &= 0x0f8f0000;
+ } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
+ rate_bitmap &= 0x0f8ff000;
+ } else {
+ if (txbw_40mhz)
+ rate_bitmap &= 0x0f8ff015;
+ else
+ rate_bitmap &= 0x0f8ff005;
+ }
+ } else {
+ if (rssi_level == RTL8XXXU_RATR_STA_HIGH) {
+ rate_bitmap &= 0x000f0000;
+ } else if (rssi_level == RTL8XXXU_RATR_STA_MID) {
+ rate_bitmap &= 0x000ff000;
+ } else {
+ if (txbw_40mhz)
+ rate_bitmap &= 0x000ff015;
+ else
+ rate_bitmap &= 0x000ff005;
+ }
+ }
+ break;
+ default:
+ ratr_idx = RATEID_IDX_BGN_40M_2SS;
+ rate_bitmap &= 0x0fffffff;
+ break;
+ }
+
+ priv->rssi_level = rssi_level;
+ priv->fops->update_rate_mask(priv, rate_bitmap, ratr_idx, sgi);
+ }
+}
+
+static void rtl8xxxu_watchdog_callback(struct work_struct *work)
+{
+ struct ieee80211_vif *vif;
+ struct rtl8xxxu_priv *priv;
+
+ priv = container_of(work, struct rtl8xxxu_priv, ra_watchdog.work);
+ vif = priv->vif;
+
+ if (vif && vif->type == NL80211_IFTYPE_STATION) {
+ int signal;
+ struct ieee80211_sta *sta;
+
+ rcu_read_lock();
+ sta = ieee80211_find_sta(vif, vif->bss_conf.bssid);
+ if (!sta) {
+ struct device *dev = &priv->udev->dev;
+
+ dev_info(dev, "%s: no sta found\n", __func__);
+ rcu_read_unlock();
+ goto out;
+ }
+ rcu_read_unlock();
+
+ signal = ieee80211_ave_rssi(vif);
+ rtl8xxxu_refresh_rate_mask(priv, signal, sta);
+ }
+
+out:
+ schedule_delayed_work(&priv->ra_watchdog, 2 * HZ);
+}
+
static int rtl8xxxu_start(struct ieee80211_hw *hw)
{
struct rtl8xxxu_priv *priv = hw->priv;
@@ -5828,6 +6044,8 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
ret = rtl8xxxu_submit_rx_urb(priv, rx_urb);
}
+
+ schedule_delayed_work(&priv->ra_watchdog, 2 * HZ);
exit:
/*
* Accept all data and mgmt frames
@@ -5879,6 +6097,8 @@ static void rtl8xxxu_stop(struct ieee80211_hw *hw)
if (priv->usb_interrupts)
rtl8xxxu_write32(priv, REG_USB_HIMR, 0);
+ cancel_delayed_work_sync(&priv->ra_watchdog);
+
rtl8xxxu_free_rx_resources(priv);
rtl8xxxu_free_tx_resources(priv);
}
@@ -6051,6 +6271,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
INIT_LIST_HEAD(&priv->rx_urb_pending_list);
spin_lock_init(&priv->rx_urb_lock);
INIT_WORK(&priv->rx_urb_wq, rtl8xxxu_rx_urb_work);
+ INIT_DELAYED_WORK(&priv->ra_watchdog, rtl8xxxu_watchdog_callback);
usb_set_intfdata(interface, hw);
--
2.20.1
^ permalink raw reply related
* -Wsizeof-array-div warnings in ethernet drivers
From: Nathan Chancellor @ 2019-09-17 7:32 UTC (permalink / raw)
To: Tom Lendacky, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
David S. Miller
Cc: Nick Desaulniers, Ilie Halip, David Bolvansky, netdev,
clang-built-linux
Hi all,
Clang recently added a new diagnostic in r371605, -Wsizeof-array-div,
that tries to warn when sizeof(X) / sizeof(Y) does not compute the
number of elements in an array X (i.e., sizeof(Y) is wrong). See that
commit for more details:
https://github.com/llvm/llvm-project/commit/3240ad4ced0d3223149b72a4fc2a4d9b67589427
Some ethernet drivers have an instance of this warning due to receive
side scaling support:
../drivers/net/ethernet/amd/xgbe/xgbe-dev.c:361:49: warning: expression
does not compute the number of elements in this array; element type is
'u8' (aka 'unsigned char'), not 'u32' (aka 'unsigned int')
[-Wsizeof-array-div]
unsigned int key_regs = sizeof(pdata->rss_key) / sizeof(u32);
~~~~~~~~~~~~~~ ^
../drivers/net/ethernet/amd/xgbe/xgbe-dev.c:361:49: note: place
parentheses around the 'sizeof(u32)' expression to silence this warning
../drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c:537:36: warning:
expression does not compute the number of elements in this array;
element type is 'u8' (aka 'unsigned char'), not 'u32' (aka 'unsigned
int') [-Wsizeof-array-div]
for (i = 0; i < (sizeof(cfg->key) / sizeof(u32)); i++) {
~~~~~~~~ ^
../drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c:537:36: note:
place parentheses around the 'sizeof(u32)' expression to silence this
warning
../drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c:2329:49: warning:
expression does not compute the number of elements in this array;
element type is 'u8' (aka 'unsigned char'), not 'u32' (aka 'unsigned
int') [-Wsizeof-array-div]
unsigned int key_regs = sizeof(pdata->rss_key) / sizeof(u32);
~~~~~~~~~~~~~~ ^
../drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c:2329:49: note: place
parentheses around the 'sizeof(u32)' expression to silence this warning
What is the reasoning behind having the key being an array of u8s but
seemlingly converting it into an array of u32s? It's not immediately
apparent from reading over the code but I am not familiar with it so I
might be making a mistake. I assume this is intentional? If so, the
warning can be silenced and we'll send patches to do so but we want to
make sure we aren't actually papering over a mistake.
Cheers!
Nathan
^ permalink raw reply
* [PATCH] dt-bindings: net: dwmac: fix 'mac-mode' type
From: Alexandru Ardelean @ 2019-09-17 10:30 UTC (permalink / raw)
To: netdev, devicetree, linux-kernel
Cc: davem, robh+dt, peppe.cavallaro, alexandre.torgue, andrew,
f.fainelli, Alexandru Ardelean
The 'mac-mode' property is similar to 'phy-mode' and 'phy-connection-type',
which are enums of mode strings.
The 'dwmac' driver supports almost all modes declared in the 'phy-mode'
enum (except for 1 or 2). But in general, there may be a case where
'mac-mode' becomes more generic and is moved as part of phylib or netdev.
In any case, the 'mac-mode' field should be made an enum, and it also makes
sense to just reference the 'phy-connection-type' from
'ethernet-controller.yaml'. That will also make it more future-proof for new
modes.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
Documentation/devicetree/bindings/net/snps,dwmac.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index ebe4537a7cce..4845e29411e4 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -113,7 +113,7 @@ properties:
const: stmmaceth
mac-mode:
- maxItems: 1
+ $ref: ethernet-controller.yaml#/properties/phy-connection-type
description:
The property is identical to 'phy-mode', and assumes that there is mode
converter in-between the MAC & PHY (e.g. GMII-to-RGMII). This converter
--
2.20.1
^ permalink raw reply related
* AW: big ICMP requests get disrupted on IPSec tunnel activation
From: Bartschies, Thomas @ 2019-09-17 7:28 UTC (permalink / raw)
To: 'David Ahern', 'netdev@vger.kernel.org'
In-Reply-To: <d0c8ebbb-3ed3-296f-d84a-6f88e641b404@gmail.com>
Hello,
thanks for the suggestion. Running pmtu.sh with kernel versions 4.19, 4.20 and even 5.2.13 made no difference. All tests were successful every time.
Although my external ping tests still failing with the newer kernels. I've ran the script after triggering my problem, to make sure all possible side effects
happening.
Please keep in mind, that even when the ICMP requests stalling, other connections still going through. Like e.g. ssh or tracepath. I would expect that
all connection types would be affected if this is a MTU problem. Am I wrong?
Any suggestions for more tests to isolate the cause?
Best regards,
--
Thomas Bartschies
CVK IT Systeme
-----Ursprüngliche Nachricht-----
Von: David Ahern [mailto:dsahern@gmail.com]
Gesendet: Freitag, 13. September 2019 19:13
An: Bartschies, Thomas <Thomas.Bartschies@cvk.de>; 'netdev@vger.kernel.org' <netdev@vger.kernel.org>
Betreff: Re: big ICMP requests get disrupted on IPSec tunnel activation
On 9/13/19 9:59 AM, Bartschies, Thomas wrote:
> Hello together,
>
> since kenel 4.20 we're observing a strange behaviour when sending big ICMP packets. An example is a packet size of 3000 bytes.
> The packets should be forwarded by a linux gateway (firewall) having multiple interfaces also acting as a vpn gateway.
>
> Test steps:
> 1. Disabled all iptables rules
> 2. Enabled the VPN IPSec Policies.
> 3. Start a ping with packet size (e.g. 3000 bytes) from a client in
> the DMZ passing the machine targeting another LAN machine 4. Ping
> works 5. Enable a VPN policy by sending pings from the gateway to a
> tunnel target. System tries to create the tunnel 6. Ping from 3. immediately stalls. No error messages. Just stops.
> 7. Stop Ping from 3. Start another without packet size parameter. Stalls also.
>
> Result:
> Connections from the client to other services on the LAN machine still
> work. Tracepath works. Only ICMP requests do not pass the gateway
> anymore. tcpdump sees them on incoming interface, but not on the outgoing LAN interface. IMCP requests to any other target IP address in LAN still work. Until one uses a bigger packet size. Then these alternative connections stall also.
>
> Flushing the policy table has no effect. Flushing the conntrack table has no effect. Setting rp_filter to loose (2) has no effect.
> Flush the route cache has no effect.
>
> Only a reboot of the gateway restores normal behavior.
>
> What can be the cause? Is this a networking bug?
>
some of these most likely will fail due to other reasons, but can you run 'tools/testing/selftests/net/pmtu.sh'[1] on 4.19 and then 4.20 and compare results. Hopefully it will shed some light on the problem and can be used to bisect to a commit that caused the regression.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/net/pmtu.sh
^ permalink raw reply
* Re: [RFC v4 3/3] vhost: introduce mdev based hardware backend
From: Jason Wang @ 2019-09-17 7:26 UTC (permalink / raw)
To: Tiwei Bie, mst, alex.williamson, maxime.coquelin
Cc: linux-kernel, kvm, virtualization, netdev, dan.daly,
cunming.liang, zhihong.wang, lingshan.zhu
In-Reply-To: <20190917010204.30376-4-tiwei.bie@intel.com>
On 2019/9/17 上午9:02, Tiwei Bie wrote:
> More details about this patch can be found from the cover
> letter for now. Only compile test has been done for now.
>
> Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
> ---
> drivers/vhost/Kconfig | 9 +
> drivers/vhost/Makefile | 3 +
> drivers/vhost/mdev.c | 462 +++++++++++++++++++++++++++++++
> drivers/vhost/vhost.c | 39 ++-
> drivers/vhost/vhost.h | 6 +
> include/uapi/linux/vhost.h | 10 +
> include/uapi/linux/vhost_types.h | 5 +
> 7 files changed, 528 insertions(+), 6 deletions(-)
> create mode 100644 drivers/vhost/mdev.c
>
> diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> index 3d03ccbd1adc..ef9783156d2e 100644
> --- a/drivers/vhost/Kconfig
> +++ b/drivers/vhost/Kconfig
> @@ -34,6 +34,15 @@ config VHOST_VSOCK
> To compile this driver as a module, choose M here: the module will be called
> vhost_vsock.
>
> +config VHOST_MDEV
> + tristate "Mediated device based hardware vhost accelerator"
> + depends on EVENTFD && VFIO && VFIO_MDEV
> + select VHOST
> + default n
> + ---help---
> + Say Y here to enable the vhost_mdev module
> + for use with hardware vhost accelerators
> +
> config VHOST
> tristate
> ---help---
> diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
> index 6c6df24f770c..ad9c0f8c6d8c 100644
> --- a/drivers/vhost/Makefile
> +++ b/drivers/vhost/Makefile
> @@ -10,4 +10,7 @@ vhost_vsock-y := vsock.o
>
> obj-$(CONFIG_VHOST_RING) += vringh.o
>
> +obj-$(CONFIG_VHOST_MDEV) += vhost_mdev.o
> +vhost_mdev-y := mdev.o
> +
> obj-$(CONFIG_VHOST) += vhost.o
> diff --git a/drivers/vhost/mdev.c b/drivers/vhost/mdev.c
> new file mode 100644
> index 000000000000..8c6597aff45e
> --- /dev/null
> +++ b/drivers/vhost/mdev.c
> @@ -0,0 +1,462 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018-2019 Intel Corporation.
> + */
> +
> +#include <linux/compat.h>
> +#include <linux/kernel.h>
> +#include <linux/miscdevice.h>
> +#include <linux/mdev.h>
> +#include <linux/module.h>
> +#include <linux/vfio.h>
> +#include <linux/vhost.h>
> +#include <linux/virtio_mdev.h>
> +
> +#include "vhost.h"
> +
> +struct vhost_mdev {
> + struct mutex mutex;
> + struct vhost_dev dev;
> + struct vhost_virtqueue *vqs;
> + int nvqs;
> + u64 state;
> + u64 features;
> + u64 acked_features;
> + struct vfio_group *vfio_group;
> + struct vfio_device *vfio_device;
> + struct mdev_device *mdev;
> +};
> +
> +/*
> + * XXX
> + * We assume virtio_mdev.ko exposes below symbols for now, as we
> + * don't have a proper way to access parent ops directly yet.
> + *
> + * virtio_mdev_readl()
> + * virtio_mdev_writel()
> + */
> +extern u32 virtio_mdev_readl(struct mdev_device *mdev, loff_t off);
> +extern void virtio_mdev_writel(struct mdev_device *mdev, loff_t off, u32 val);
Need to consider a better approach, I feel we should do it through some
kind of mdev driver instead of talk to mdev device directly.
> +
> +static u8 mdev_get_status(struct mdev_device *mdev)
> +{
> + return virtio_mdev_readl(mdev, VIRTIO_MDEV_STATUS);
> +}
> +
> +static void mdev_set_status(struct mdev_device *mdev, u8 status)
> +{
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_STATUS, status);
> +}
> +
> +static void mdev_add_status(struct mdev_device *mdev, u8 status)
> +{
> + status |= mdev_get_status(mdev);
> + mdev_set_status(mdev, status);
> +}
> +
> +static void mdev_reset(struct mdev_device *mdev)
> +{
> + mdev_set_status(mdev, 0);
> +}
> +
> +static void handle_vq_kick(struct vhost_work *work)
> +{
> + struct vhost_virtqueue *vq = container_of(work, struct vhost_virtqueue,
> + poll.work);
> + struct vhost_mdev *m = container_of(vq->dev, struct vhost_mdev, dev);
> +
> + virtio_mdev_writel(m->mdev, VIRTIO_MDEV_QUEUE_NOTIFY, vq - m->vqs);
> +}
> +
> +static long vhost_mdev_start_backend(struct vhost_mdev *m)
> +{
> + struct mdev_device *mdev = m->mdev;
> + u64 features = m->acked_features;
> + u64 addr;
> + struct vhost_virtqueue *vq;
> + int queue_id;
> +
> + features |= 1ULL << VIRTIO_F_IOMMU_PLATFORM;
Is it better to get this feature from backend?
> +
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_DRIVER_FEATURES_SEL, 1);
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_DRIVER_FEATURES,
> + (u32)(features >> 32));
> +
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_DRIVER_FEATURES_SEL, 0);
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_DRIVER_FEATURES,
> + (u32)features);
> +
> + mdev_add_status(mdev, VIRTIO_CONFIG_S_FEATURES_OK);
> + if (!(mdev_get_status(mdev) & VIRTIO_CONFIG_S_FEATURES_OK))
> + return -ENODEV;
> +
> + for (queue_id = 0; queue_id < m->nvqs; queue_id++) {
> + vq = &m->vqs[queue_id];
> +
> + if (!vq->desc || !vq->avail || !vq->used)
> + break;
> +
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_NUM, vq->num);
> +
> + if (!vhost_translate_ring_addr(vq, (u64)vq->desc,
> + vhost_get_desc_size(vq, vq->num),
> + &addr))
> + return -EINVAL;
Interesting, any reason for doing such kinds of translation to HVA? I
believe the add should already an IOVA that has been map by VFIO.
> +
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_DESC_LOW, addr);
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_DESC_HIGH,
> + (addr >> 32));
> +
> + if (!vhost_translate_ring_addr(vq, (u64)vq->avail,
> + vhost_get_avail_size(vq, vq->num),
> + &addr))
> + return -EINVAL;
> +
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_AVAIL_LOW, addr);
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_AVAIL_HIGH,
> + (addr >> 32));
> +
> + if (!vhost_translate_ring_addr(vq, (u64)vq->used,
> + vhost_get_used_size(vq, vq->num),
> + &addr))
> + return -EINVAL;
> +
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_USED_LOW, addr);
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_USED_HIGH,
> + (addr >> 32));
> +
> + // XXX: we need to support set_vring_base
I'm working on V2 that support this API.
> +
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_READY, 1);
> + }
> +
> + // XXX: we need to setup interrupt as well
V2 will have a better interrupt API like some kind of callback. It could
be as simple as a wrapper of eventfd_signal().
> +
> + mdev_add_status(mdev, VIRTIO_CONFIG_S_DRIVER_OK);
> + return 0;
> +}
> +
> +static long vhost_mdev_stop_backend(struct vhost_mdev *m)
> +{
> + struct mdev_device *mdev = m->mdev;
> +
> + mdev_reset(mdev);
> + mdev_add_status(mdev, VIRTIO_CONFIG_S_ACKNOWLEDGE);
> + mdev_add_status(mdev, VIRTIO_CONFIG_S_DRIVER);
> + return 0;
> +}
> +
> +static long vhost_set_state(struct vhost_mdev *m, u64 __user *statep)
> +{
> + u64 state;
> + long r;
> +
> + if (copy_from_user(&state, statep, sizeof(state)))
> + return -EFAULT;
> +
> + if (state >= VHOST_MDEV_S_MAX)
> + return -EINVAL;
> +
> + if (m->state == state)
> + return 0;
> +
> + m->state = state;
> +
> + switch (m->state) {
> + case VHOST_MDEV_S_RUNNING:
> + r = vhost_mdev_start_backend(m);
> + break;
> + case VHOST_MDEV_S_STOPPED:
> + r = vhost_mdev_stop_backend(m);
> + break;
> + default:
> + r = -EINVAL;
> + break;
> + }
> +
> + return r;
> +}
> +
> +static long vhost_get_features(struct vhost_mdev *m, u64 __user *featurep)
> +{
> + if (copy_to_user(featurep, &m->features, sizeof(m->features)))
> + return -EFAULT;
> + return 0;
> +}
> +
> +static long vhost_set_features(struct vhost_mdev *m, u64 __user *featurep)
> +{
> + u64 features;
> +
> + if (copy_from_user(&features, featurep, sizeof(features)))
> + return -EFAULT;
> +
> + if (features & ~m->features)
> + return -EINVAL;
> +
> + m->acked_features = features;
> +
> + return 0;
> +}
> +
> +static long vhost_get_vring_base(struct vhost_mdev *m, void __user *argp)
> +{
> + struct vhost_virtqueue *vq;
> + u32 idx;
> + long r;
> +
> + r = get_user(idx, (u32 __user *)argp);
> + if (r < 0)
> + return r;
> + if (idx >= m->nvqs)
> + return -ENOBUFS;
> +
> + vq = &m->vqs[idx];
> +
> + // XXX: we need to support get_vring_base
> + //vq->last_avail_idx = virtio_mdev_readl(b->mdev, ...);
> +
> + return vhost_vring_ioctl(&m->dev, VHOST_GET_VRING_BASE, argp);
> +}
> +
> +static void vhost_mdev_release_backend(struct vhost_mdev *m)
> +{
> + if (!m->mdev)
> + return;
> +
> + if (m->state != VHOST_MDEV_S_STOPPED) {
> + m->state = VHOST_MDEV_S_STOPPED;
> + vhost_mdev_stop_backend(m);
> + }
> +
> + vhost_dev_stop(&m->dev);
> + vhost_dev_cleanup(&m->dev);
> +
> + kfree(m->dev.vqs);
> + kfree(m->vqs);
> +
> + vfio_device_put(m->vfio_device);
> + vfio_group_put_external_user(m->vfio_group);
> +
> + m->mdev = NULL;
> +}
> +
> +static long vhost_mdev_set_backend(struct vhost_mdev *m,
> + struct vhost_mdev_backend __user *argp)
> +{
> + struct vhost_mdev_backend backend;
> + struct mdev_device *mdev;
> + struct vhost_dev *dev;
> + struct vhost_virtqueue **vqs;
> + struct file *file;
> + struct vfio_device *device;
> + struct vfio_group *group;
> + unsigned long magic;
> + u64 features;
> + int i, nvqs;
> + long r;
> +
> + vhost_mdev_release_backend(m);
> +
> + if (copy_from_user(&backend, argp, sizeof(backend))) {
> + r = -EFAULT;
> + goto err;
> + }
> +
> + file = fget(backend.group_fd);
> + if (!file) {
> + r = -EBADF;
> + goto err;
> + }
> +
> + group = vfio_group_get_external_user(file);
> + fput(file);
> + if (IS_ERR(group)) {
> + r = PTR_ERR(group);
> + goto err;
> + }
> +
> + device = vfio_device_get_from_fd(group, backend.device_fd);
> + if (!IS_ERR(device)) {
> + r = PTR_ERR(device);
> + goto err_put_group;
> + }
> +
> + if (!vfio_device_ops_match(device, &vfio_mdev_dev_ops)) {
> + r = -EINVAL;
> + goto err_put_device;
> + }
It looks to me that we can avoid to expose vfio_mdev_dev_ops here.
> +
> + mdev = vfio_device_data(m->vfio_device);
> +
> + magic = virtio_mdev_readl(mdev, VIRTIO_MDEV_MAGIC_VALUE);
> + if (magic != ('v' | 'i' << 8 | 'r' << 16 | 't' << 24)) {
> + r = -ENODEV;
> + goto err_put_device;
> + }
> +
> + mdev_reset(mdev);
> + mdev_add_status(mdev, VIRTIO_CONFIG_S_ACKNOWLEDGE);
> + mdev_add_status(mdev, VIRTIO_CONFIG_S_DRIVER);
> +
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_DEVICE_FEATURES_SEL, 1);
> + features = virtio_mdev_readl(mdev, VIRTIO_MDEV_DEVICE_FEATURES);
> + features <<= 32;
> +
> + virtio_mdev_writel(mdev, VIRTIO_MDEV_DEVICE_FEATURES_SEL, 0);
> + features |= virtio_mdev_readl(mdev, VIRTIO_MDEV_DEVICE_FEATURES);
> +
> + if (!(features & (1ULL << VIRTIO_F_IOMMU_PLATFORM))) {
> + r = -EINVAL;
> + goto err_put_device;
> + }
> +
> + m->features = features;
> +
> + nvqs = virtio_mdev_readl(mdev, VIRTIO_MDEV_QUEUE_NUM_MAX);
> + m->nvqs = nvqs;
> +
> + m->vqs = kmalloc_array(nvqs, sizeof(struct vhost_virtqueue),
> + GFP_KERNEL);
> + if (!m->vqs) {
> + r = -ENOMEM;
> + goto err_put_device;
> + }
> +
> + vqs = kmalloc_array(nvqs, sizeof(*vqs), GFP_KERNEL);
> + if (!vqs) {
> + r = -ENOMEM;
> + goto err_free_vqs;
> + }
> +
> + dev = &m->dev;
> + for (i = 0; i < nvqs; i++) {
> + vqs[i] = &m->vqs[i];
> + vqs[i]->handle_kick = handle_vq_kick;
> + }
> + vhost_dev_init(dev, vqs, nvqs, 0, 0, 0);
> +
> + m->vfio_group = group;
> + m->vfio_device = device;
> + m->mdev = mdev;
> +
> + return 0;
> +
> +err_free_vqs:
> + kfree(m->vqs);
> +err_put_device:
> + vfio_device_put(device);
> +err_put_group:
> + vfio_group_put_external_user(group);
> +err:
> + return r;
> +}
> +
> +static int vhost_mdev_open(struct inode *inode, struct file *f)
> +{
> + struct vhost_mdev *m;
> +
> + m = kzalloc(sizeof(*m), GFP_KERNEL | __GFP_RETRY_MAYFAIL);
> + if (!m)
> + return -ENOMEM;
> +
> + mutex_init(&m->mutex);
> + f->private_data = m;
> +
> + return 0;
> +}
> +
> +static int vhost_mdev_release(struct inode *inode, struct file *f)
> +{
> + struct vhost_mdev *m = f->private_data;
> +
> + vhost_mdev_release_backend(m);
> + mutex_destroy(&m->mutex);
> + kfree(m);
> +
> + return 0;
> +}
> +
> +static long vhost_mdev_ioctl(struct file *f, unsigned int cmd,
> + unsigned long arg)
> +{
> + void __user *argp = (void __user *)arg;
> + struct vhost_mdev *m = f->private_data;
> + long r;
> +
> + mutex_lock(&m->mutex);
> +
> + if (cmd == VHOST_MDEV_SET_BACKEND) {
> + r = vhost_mdev_set_backend(m, argp);
> + goto done;
> + }
> +
> + if (!m->mdev) {
> + r = -EINVAL;
> + goto done;
> + }
> +
> + switch (cmd) {
> + case VHOST_MDEV_SET_STATE:
> + r = vhost_set_state(m, argp);
> + break;
> + case VHOST_GET_FEATURES:
> + r = vhost_get_features(m, argp);
> + break;
> + case VHOST_SET_FEATURES:
> + r = vhost_set_features(m, argp);
> + break;
> + case VHOST_GET_VRING_BASE:
> + r = vhost_get_vring_base(m, argp);
> + break;
> + default:
> + r = vhost_dev_ioctl(&m->dev, cmd, argp);
> + if (r == -ENOIOCTLCMD)
> + r = vhost_vring_ioctl(&m->dev, cmd, argp);
> + }
> +
> +done:
> + mutex_lock(&m->mutex);
> + return r;
> +}
> +
> +#ifdef CONFIG_COMPAT
> +static long vhost_mdev_compat_ioctl(struct file *f, unsigned int ioctl,
> + unsigned long arg)
> +{
> + return vhost_mdev_ioctl(f, ioctl, (unsigned long)compat_ptr(arg));
> +}
> +#endif
> +
> +static const struct file_operations vhost_mdev_fops = {
> + .owner = THIS_MODULE,
> + .release = vhost_mdev_release,
> + .unlocked_ioctl = vhost_mdev_ioctl,
> +#ifdef CONFIG_COMPAT
> + .compat_ioctl = vhost_mdev_compat_ioctl,
> +#endif
> + .open = vhost_mdev_open,
> + .llseek = noop_llseek,
> +};
> +
> +static struct miscdevice vhost_mdev_misc = {
> + .minor = MISC_DYNAMIC_MINOR,
> + .name = "vhost-mdev",
> + .fops = &vhost_mdev_fops,
> +};
> +
> +static int __init vhost_mdev_init(void)
> +{
> + return misc_register(&vhost_mdev_misc);
> +}
> +module_init(vhost_mdev_init);
> +
> +static void __exit vhost_mdev_exit(void)
> +{
> + misc_deregister(&vhost_mdev_misc);
> +}
> +module_exit(vhost_mdev_exit);
> +
> +MODULE_VERSION("0.0.0");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("Hardware vhost accelerator abstraction");
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 5dc174ac8cac..0f7236a17a56 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -426,8 +426,7 @@ bool vhost_exceeds_weight(struct vhost_virtqueue *vq,
> }
> EXPORT_SYMBOL_GPL(vhost_exceeds_weight);
>
> -static size_t vhost_get_avail_size(struct vhost_virtqueue *vq,
> - unsigned int num)
> +size_t vhost_get_avail_size(struct vhost_virtqueue *vq, unsigned int num)
> {
> size_t event __maybe_unused =
> vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
> @@ -435,9 +434,9 @@ static size_t vhost_get_avail_size(struct vhost_virtqueue *vq,
> return sizeof(*vq->avail) +
> sizeof(*vq->avail->ring) * num + event;
> }
> +EXPORT_SYMBOL_GPL(vhost_get_avail_size);
>
> -static size_t vhost_get_used_size(struct vhost_virtqueue *vq,
> - unsigned int num)
> +size_t vhost_get_used_size(struct vhost_virtqueue *vq, unsigned int num)
> {
> size_t event __maybe_unused =
> vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
> @@ -445,12 +444,13 @@ static size_t vhost_get_used_size(struct vhost_virtqueue *vq,
> return sizeof(*vq->used) +
> sizeof(*vq->used->ring) * num + event;
> }
> +EXPORT_SYMBOL_GPL(vhost_get_used_size);
>
> -static size_t vhost_get_desc_size(struct vhost_virtqueue *vq,
> - unsigned int num)
> +size_t vhost_get_desc_size(struct vhost_virtqueue *vq, unsigned int num)
> {
> return sizeof(*vq->desc) * num;
> }
> +EXPORT_SYMBOL_GPL(vhost_get_desc_size);
>
> void vhost_dev_init(struct vhost_dev *dev,
> struct vhost_virtqueue **vqs, int nvqs,
> @@ -2617,6 +2617,33 @@ struct vhost_msg_node *vhost_dequeue_msg(struct vhost_dev *dev,
> }
> EXPORT_SYMBOL_GPL(vhost_dequeue_msg);
>
> +bool vhost_translate_ring_addr(struct vhost_virtqueue *vq, u64 ring_addr,
> + u64 len, u64 *addr)
> +{
> + struct vhost_umem *umem = vq->umem;
> + struct vhost_umem_node *u;
> +
> + if (vhost_overflow(ring_addr, len))
> + return false;
> +
> + if (vq->iotlb) {
> + /* Ring address is already IOVA */
> + *addr = ring_addr;
> + return true;
> + }
> +
> + /* Ring address is host virtual address. */
> + list_for_each_entry(u, &umem->umem_list, link) {
> + if (u->userspace_addr <= ring_addr &&
> + u->userspace_addr + u->size >= ring_addr + len) {
> + *addr = ring_addr - u->userspace_addr + u->start;
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +EXPORT_SYMBOL_GPL(vhost_translate_ring_addr);
As we've discussed, this is necessary.
Thanks
>
> static int __init vhost_init(void)
> {
> diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
> index e9ed2722b633..294a6bcb6adf 100644
> --- a/drivers/vhost/vhost.h
> +++ b/drivers/vhost/vhost.h
> @@ -189,6 +189,12 @@ long vhost_dev_ioctl(struct vhost_dev *, unsigned int ioctl, void __user *argp);
> long vhost_vring_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *argp);
> bool vhost_vq_access_ok(struct vhost_virtqueue *vq);
> bool vhost_log_access_ok(struct vhost_dev *);
> +bool vhost_translate_ring_addr(struct vhost_virtqueue *vq, u64 ring_addr,
> + u64 len, u64 *addr);
> +
> +size_t vhost_get_avail_size(struct vhost_virtqueue *vq, unsigned int num);
> +size_t vhost_get_used_size(struct vhost_virtqueue *vq, unsigned int num);
> +size_t vhost_get_desc_size(struct vhost_virtqueue *vq, unsigned int num);
>
> int vhost_get_vq_desc(struct vhost_virtqueue *,
> struct iovec iov[], unsigned int iov_count,
> diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
> index 40d028eed645..7213aedc8506 100644
> --- a/include/uapi/linux/vhost.h
> +++ b/include/uapi/linux/vhost.h
> @@ -116,4 +116,14 @@
> #define VHOST_VSOCK_SET_GUEST_CID _IOW(VHOST_VIRTIO, 0x60, __u64)
> #define VHOST_VSOCK_SET_RUNNING _IOW(VHOST_VIRTIO, 0x61, int)
>
> +/* VHOST_MDEV specific defines */
> +
> +#define VHOST_MDEV_SET_BACKEND _IOW(VHOST_VIRTIO, 0x70, \
> + struct vhost_mdev_backend)
> +#define VHOST_MDEV_SET_STATE _IOW(VHOST_VIRTIO, 0x71, __u64)
> +
> +#define VHOST_MDEV_S_STOPPED 0
> +#define VHOST_MDEV_S_RUNNING 1
> +#define VHOST_MDEV_S_MAX 2
> +
> #endif
> diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h
> index c907290ff065..f06f0dbb7e51 100644
> --- a/include/uapi/linux/vhost_types.h
> +++ b/include/uapi/linux/vhost_types.h
> @@ -119,6 +119,11 @@ struct vhost_scsi_target {
> unsigned short reserved;
> };
>
> +struct vhost_mdev_backend {
> + int group_fd;
> + int device_fd;
> +};
> +
> /* Feature bits */
> /* Log all write descriptors. Can be changed while device is active. */
> #define VHOST_F_LOG_ALL 26
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: net: dwmac: document 'mac-mode' property
From: Ardelean, Alexandru @ 2019-09-17 7:21 UTC (permalink / raw)
To: robh@kernel.org
Cc: andrew@lunn.ch, davem@davemloft.net, alexandre.torgue@st.com,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
peppe.cavallaro@st.com, netdev@vger.kernel.org,
f.fainelli@gmail.com
In-Reply-To: <b5065fcfaaf8bcb7bc532a8eb9f54949da838965.camel@analog.com>
On Mon, 2019-09-16 at 12:49 +0300, Alexandru Ardelean wrote:
> On Fri, 2019-09-13 at 15:36 +0100, Rob Herring wrote:
> > [External]
> >
> > On Fri, Sep 06, 2019 at 04:02:56PM +0300, Alexandru Ardelean wrote:
> > > This change documents the 'mac-mode' property that was introduced in
> > > the
> > > 'stmmac' driver to support passive mode converters that can sit in-
> > > between
> > > the MAC & PHY.
> > >
> > > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > > ---
> > > Documentation/devicetree/bindings/net/snps,dwmac.yaml | 8 ++++++++
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > index c78be15704b9..ebe4537a7cce 100644
> > > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > @@ -112,6 +112,14 @@ properties:
> > > reset-names:
> > > const: stmmaceth
> > >
> > > + mac-mode:
> > > + maxItems: 1
> >
> > Is this an array because {min,max}Items is for arrays? It should be
> > defined as a string with possible values.
> >
> > As this property is the same as another, you can do this:
> >
> > $ref: ethernet-controller.yaml#/properties/phy-connection-type
> >
> > Unless only a small subset of those values are valid here, then you
> > may
> > want to list them here.
> >
>
> Ack.
> Thank you.
>
> Will investigate and re-spin.
Looking at '$ref: ethernet-controller.yaml#/properties/phy-connection-type'
it looks like 'mac-mode' could cover almost all 'phy-connection-type'
except for a few (1 or 2). The 'dwmac' driver is pretty complex/big.
There was a note that Andrew made on a previous change, that we could have
a 'mac-mode' (similar to 'phy-mode') and that could become generic (either
in phylib or maybe somewhere else in netdev).
In any case, the conclusion [from my side] would be that
'$ref: ethernet-controller.yaml#/properties/phy-connection-type'
could work, and be sufficiently future-proof.
Thanks
Alex
>
>
> > > + description:
> > > + The property is identical to 'phy-mode', and assumes that
> > > there is mode
> > > + converter in-between the MAC & PHY (e.g. GMII-to-RGMII). This
> > > converter
> > > + can be passive (no SW requirement), and requires that the MAC
> > > operate
> > > + in a different mode than the PHY in order to function.
> > > +
> > > snps,axi-config:
> > > $ref: /schemas/types.yaml#definitions/phandle
> > > description:
> > > --
> > > 2.20.1
> > >
^ permalink raw reply
* Re: [PATCH] ath10k: Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element
From: Kalle Valo @ 2019-09-17 7:16 UTC (permalink / raw)
To: zhong jiang
Cc: davem, ath10k, linux-wireless, zhongjiang, netdev, linux-kernel
In-Reply-To: <1567582878-18739-1-git-send-email-zhongjiang@huawei.com>
zhong jiang <zhongjiang@huawei.com> wrote:
> With the help of Coccinelle, ARRAY_SIZE can be replaced in ath10k_snoc_wlan_enable.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
I already got an identical patch so dropping this one.
error: patch failed: drivers/net/wireless/ath/ath10k/snoc.c:976
error: drivers/net/wireless/ath/ath10k/snoc.c: patch does not apply
stg import: Diff does not apply cleanly
--
https://patchwork.kernel.org/patch/11129531/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] selftests/net: replace AF_MAX with INT_MAX in socket.c
From: Marcelo Henrique Cerri @ 2019-09-17 7:12 UTC (permalink / raw)
To: shuah; +Cc: David S. Miller, netdev, linux-kselftest, linux-kernel
In-Reply-To: <212adcf8-566e-e06d-529f-f0ac18bd6a35@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]
So the problem arises because the headers we have in userspace might
be older and not match what we have in the kernel. In that case, the
actual value of AF_MAX in the userspace headers might be a valid
protocol family in the new kernel.
That happens relatively often for us because we support different
kernel versions at the same time in a given Ubuntu series.
An alternative is to use the headers we have in the kernel tree, but I
believe that might cause other issues.
On Mon, Sep 16, 2019 at 10:09:13AM -0600, shuah wrote:
> On 9/16/19 9:03 AM, Marcelo Henrique Cerri wrote:
> > Use INT_MAX instead of AF_MAX, since libc might have a smaller value
> > of AF_MAX than the kernel, what causes the test to fail.
> >
> > Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
> > ---
> > tools/testing/selftests/net/socket.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/testing/selftests/net/socket.c b/tools/testing/selftests/net/socket.c
> > index afca1ead677f..10e75ba90124 100644
> > --- a/tools/testing/selftests/net/socket.c
> > +++ b/tools/testing/selftests/net/socket.c
> > @@ -6,6 +6,7 @@
> > #include <sys/types.h>
> > #include <sys/socket.h>
> > #include <netinet/in.h>
> > +#include <limits.h>
> > struct socket_testcase {
> > int domain;
> > @@ -24,7 +25,10 @@ struct socket_testcase {
> > };
> > static struct socket_testcase tests[] = {
> > - { AF_MAX, 0, 0, -EAFNOSUPPORT, 0 },
> > + /* libc might have a smaller value of AF_MAX than the kernel
> > + * actually supports, so use INT_MAX instead.
> > + */
> > + { INT_MAX, 0, 0, -EAFNOSUPPORT, 0 },
> > { AF_INET, SOCK_STREAM, IPPROTO_TCP, 0, 1 },
> > { AF_INET, SOCK_DGRAM, IPPROTO_TCP, -EPROTONOSUPPORT, 1 },
> > { AF_INET, SOCK_DGRAM, IPPROTO_UDP, 0, 1 },
> >
>
> What failure are you seeing? It sounds arbitrary to use INT_MAX
> instead of AF_MAX. I think it is important to understand the
> failure first.
>
> Please note that AF_MAX is widely used in the kernel.
>
> thanks,
> -- Shuah
--
Regards,
Marcelo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* KASAN: slab-out-of-bounds Read in fib6_nh_get_excptn_bucket
From: syzbot @ 2019-09-17 6:57 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 505a8ec7 Revert "drm/i915/userptr: Acquire the page lock a..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=176a0831600000
kernel config: https://syzkaller.appspot.com/x/.config?x=861a6f31647968de
dashboard link: https://syzkaller.appspot.com/bug?extid=ce7be3d2a9d20f463b76
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+ce7be3d2a9d20f463b76@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-out-of-bounds in fib6_nh_get_excptn_bucket+0x198/0x1b0
net/ipv6/route.c:1591
Read of size 8 at addr ffff8880a06dd6f8 by task syz-executor.2/11374
CPU: 1 PID: 11374 Comm: syz-executor.2 Not tainted 5.3.0-rc8+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351
__kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482
kasan_report+0x12/0x17 mm/kasan/common.c:618
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
fib6_nh_get_excptn_bucket+0x198/0x1b0 net/ipv6/route.c:1591
fib6_nh_flush_exceptions+0x37/0x2d0 net/ipv6/route.c:1719
fib6_nh_release+0x84/0x3a0 net/ipv6/route.c:3503
fib6_info_destroy_rcu+0x11e/0x150 net/ipv6/ip6_fib.c:174
__rcu_reclaim kernel/rcu/rcu.h:222 [inline]
rcu_do_batch kernel/rcu/tree.c:2114 [inline]
rcu_core+0x67f/0x1580 kernel/rcu/tree.c:2314
rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2323
__do_softirq+0x262/0x98c kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x19b/0x1e0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:537 [inline]
smp_apic_timer_interrupt+0x1a3/0x610 arch/x86/kernel/apic/apic.c:1137
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830
</IRQ>
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:768
[inline]
RIP: 0010:lock_acquire+0x20b/0x410 kernel/locking/lockdep.c:4415
Code: 8c 08 00 00 00 00 00 00 48 c1 e8 03 80 3c 10 00 0f 85 d3 01 00 00 48
83 3d a1 30 7a 07 00 0f 84 53 01 00 00 48 8b 7d c8 57 9d <0f> 1f 44 00 00
48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 65 8b
RSP: 0018:ffff8880261ef638 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
RAX: 1ffffffff11a5e8a RBX: ffff88800df3a500 RCX: 0000000000000002
RDX: dffffc0000000000 RSI: 0000000000000000 RDI: 0000000000000286
RBP: ffff8880261ef680 R08: 0000000000000000 R09: 0000000000000000
R10: fffffbfff134afaf R11: ffff88800df3a500 R12: ffffffff88dac3c0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000002
rcu_lock_acquire include/linux/rcupdate.h:208 [inline]
rcu_read_lock include/linux/rcupdate.h:592 [inline]
lock_page_memcg+0x39/0x240 mm/memcontrol.c:2086
page_remove_file_rmap mm/rmap.c:1218 [inline]
page_remove_rmap+0x5d6/0x1190 mm/rmap.c:1303
zap_pte_range mm/memory.c:1059 [inline]
zap_pmd_range mm/memory.c:1161 [inline]
zap_pud_range mm/memory.c:1190 [inline]
zap_p4d_range mm/memory.c:1211 [inline]
unmap_page_range+0xd45/0x2170 mm/memory.c:1232
unmap_single_vma+0x19d/0x300 mm/memory.c:1277
unmap_vmas+0x135/0x280 mm/memory.c:1309
exit_mmap+0x2ba/0x530 mm/mmap.c:3145
__mmput kernel/fork.c:1064 [inline]
mmput+0x179/0x4d0 kernel/fork.c:1085
exit_mm kernel/exit.c:547 [inline]
do_exit+0x84e/0x2e50 kernel/exit.c:866
do_group_exit+0x135/0x360 kernel/exit.c:983
get_signal+0x47c/0x2500 kernel/signal.c:2734
do_signal+0x87/0x1700 arch/x86/kernel/signal.c:815
exit_to_usermode_loop+0x286/0x380 arch/x86/entry/common.c:159
prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
do_syscall_64+0x5a9/0x6a0 arch/x86/entry/common.c:299
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4598e9
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fbaefd09c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: 000000000000004c RBX: 0000000000000003 RCX: 00000000004598e9
RDX: 0000000000000000 RSI: 0000000020000380 RDI: 0000000000000004
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fbaefd0a6d4
R13: 00000000004c711b R14: 00000000004dc828 R15: 00000000ffffffff
Allocated by task 11374:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:493 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:466
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:507
kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3550
kmalloc include/linux/slab.h:552 [inline]
kzalloc include/linux/slab.h:748 [inline]
fib6_info_alloc+0xb6/0x1b0 net/ipv6/ip6_fib.c:154
ip6_route_info_create+0x2fe/0x1530 net/ipv6/route.c:3605
ip6_route_add+0x27/0xc0 net/ipv6/route.c:3697
inet6_rtm_newroute+0x16c/0x180 net/ipv6/route.c:5261
rtnetlink_rcv_msg+0x463/0xb00 net/core/rtnetlink.c:5223
netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5241
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:657
___sys_sendmsg+0x803/0x920 net/socket.c:2311
__sys_sendmsg+0x105/0x1d0 net/socket.c:2356
__do_sys_sendmsg net/socket.c:2365 [inline]
__se_sys_sendmsg net/socket.c:2363 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 16:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:455
kasan_slab_free+0xe/0x10 mm/kasan/common.c:463
__cache_free mm/slab.c:3425 [inline]
kfree+0x10a/0x2c0 mm/slab.c:3756
__rcu_reclaim kernel/rcu/rcu.h:215 [inline]
rcu_do_batch kernel/rcu/tree.c:2114 [inline]
rcu_core+0x7a3/0x1580 kernel/rcu/tree.c:2314
rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2323
__do_softirq+0x262/0x98c kernel/softirq.c:292
The buggy address belongs to the object at ffff8880a06dd600
which belongs to the cache kmalloc-192 of size 192
The buggy address is located 56 bytes to the right of
192-byte region [ffff8880a06dd600, ffff8880a06dd6c0)
The buggy address belongs to the page:
page:ffffea000281b740 refcount:1 mapcount:0 mapping:ffff8880aa400000
index:0x0
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea00024f84c8 ffffea0002622288 ffff8880aa400000
raw: 0000000000000000 ffff8880a06dd000 0000000100000010 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880a06dd580: 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8880a06dd600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8880a06dd680: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8880a06dd700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8880a06dd780: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
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.
^ permalink raw reply
* INFO: task hung in ovs_dp_cmd_new
From: syzbot @ 2019-09-17 6:54 UTC (permalink / raw)
To: davem, dev, linux-kernel, netdev, pshelar, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 2339cd6c bpf: fix precision tracking of stack slots
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=14707b01600000
kernel config: https://syzkaller.appspot.com/x/.config?x=b89bb446a3faaba4
dashboard link: https://syzkaller.appspot.com/bug?extid=a9d62dbe662772066f3c
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a9d62dbe662772066f3c@syzkaller.appspotmail.com
INFO: task syz-executor.0:3410 blocked for more than 143 seconds.
Not tainted 5.3.0-rc7+ #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.0 D26056 3410 18433 0x00000004
Call Trace:
context_switch kernel/sched/core.c:3254 [inline]
__schedule+0x755/0x1580 kernel/sched/core.c:3880
schedule+0xd9/0x260 kernel/sched/core.c:3947
schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:4006
__mutex_lock_common kernel/locking/mutex.c:1007 [inline]
__mutex_lock+0x7b0/0x13c0 kernel/locking/mutex.c:1077
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1092
ovs_lock net/openvswitch/datapath.c:105 [inline]
ovs_dp_cmd_new+0x579/0xea0 net/openvswitch/datapath.c:1613
genl_family_rcv_msg+0x74b/0xf90 net/netlink/genetlink.c:629
genl_rcv_msg+0xca/0x170 net/netlink/genetlink.c:654
netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
genl_rcv+0x29/0x40 net/netlink/genetlink.c:665
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:657
___sys_sendmsg+0x803/0x920 net/socket.c:2311
__sys_sendmsg+0x105/0x1d0 net/socket.c:2356
__do_sys_sendmsg net/socket.c:2365 [inline]
__se_sys_sendmsg net/socket.c:2363 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4598e9
Code: Bad RIP value.
RSP: 002b:00007fa2501cdc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004598e9
RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000004
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa2501ce6d4
R13: 00000000004c7777 R14: 00000000004dcfd8 R15: 00000000ffffffff
INFO: task syz-executor.0:3414 blocked for more than 143 seconds.
Not tainted 5.3.0-rc7+ #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.0 D26136 3414 18433 0x00000004
Call Trace:
context_switch kernel/sched/core.c:3254 [inline]
__schedule+0x755/0x1580 kernel/sched/core.c:3880
schedule+0xd9/0x260 kernel/sched/core.c:3947
schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:4006
__mutex_lock_common kernel/locking/mutex.c:1007 [inline]
__mutex_lock+0x7b0/0x13c0 kernel/locking/mutex.c:1077
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1092
ovs_lock net/openvswitch/datapath.c:105 [inline]
ovs_dp_cmd_new+0x579/0xea0 net/openvswitch/datapath.c:1613
genl_family_rcv_msg+0x74b/0xf90 net/netlink/genetlink.c:629
genl_rcv_msg+0xca/0x170 net/netlink/genetlink.c:654
netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
genl_rcv+0x29/0x40 net/netlink/genetlink.c:665
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:657
___sys_sendmsg+0x803/0x920 net/socket.c:2311
__sys_sendmsg+0x105/0x1d0 net/socket.c:2356
__do_sys_sendmsg net/socket.c:2365 [inline]
__se_sys_sendmsg net/socket.c:2363 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4598e9
Code: Bad RIP value.
RSP: 002b:00007fa2501acc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004598e9
RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000006
RBP: 000000000075bfc8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa2501ad6d4
R13: 00000000004c7777 R14: 00000000004dcfd8 R15: 00000000ffffffff
INFO: task syz-executor.0:3416 blocked for more than 144 seconds.
Not tainted 5.3.0-rc7+ #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.0 D25968 3416 18433 0x00000004
Call Trace:
context_switch kernel/sched/core.c:3254 [inline]
__schedule+0x755/0x1580 kernel/sched/core.c:3880
schedule+0xd9/0x260 kernel/sched/core.c:3947
schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:4006
__mutex_lock_common kernel/locking/mutex.c:1007 [inline]
__mutex_lock+0x7b0/0x13c0 kernel/locking/mutex.c:1077
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1092
ovs_lock net/openvswitch/datapath.c:105 [inline]
ovs_dp_cmd_new+0x579/0xea0 net/openvswitch/datapath.c:1613
genl_family_rcv_msg+0x74b/0xf90 net/netlink/genetlink.c:629
genl_rcv_msg+0xca/0x170 net/netlink/genetlink.c:654
netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
genl_rcv+0x29/0x40 net/netlink/genetlink.c:665
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:657
___sys_sendmsg+0x803/0x920 net/socket.c:2311
__sys_sendmsg+0x105/0x1d0 net/socket.c:2356
__do_sys_sendmsg net/socket.c:2365 [inline]
__se_sys_sendmsg net/socket.c:2363 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363
do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4598e9
Code: 24 18 0f b6 05 2f d1 3b 01 3c 01 76 0a 48 8b 6c 24 18 48 83 c4 20 c3
75 07 e8 63 08 fd ff 0f 0b c6 05 11 d1 3b 01 01 48 b8 00 <00> 00 00 00 00
f0 7f 48 89 04 24 e8 a7 dd fa ff f2 0f 10 44 24 08
RSP: 002b:00007fa25018bc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004598e9
RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000007
RBP: 000000000075c070 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa25018c6d4
R13: 00000000004c7777 R14: 00000000004dcfd8 R15: 00000000ffffffff
INFO: lockdep is turned off.
NMI backtrace for cpu 1
CPU: 1 PID: 1057 Comm: khungtaskd Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
nmi_cpu_backtrace.cold+0x70/0xb2 lib/nmi_backtrace.c:101
nmi_trigger_cpumask_backtrace+0x23b/0x28b lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_all_cpu_backtrace include/linux/nmi.h:146 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:205 [inline]
watchdog+0x9d0/0xef0 kernel/hung_task.c:289
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0 skipped: idling at native_safe_halt+0xe/0x10
arch/x86/include/asm/irqflags.h:60
---
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.
^ permalink raw reply
* [PATCH] rtlwifi: rtl8723ae: Remove unused 'rtstatus' variable
From: Austin Kim @ 2019-09-17 6:50 UTC (permalink / raw)
To: pkshih, kvalo, davem; +Cc: linux-wireless, netdev, linux-kernel, austindh.kim
'rtstatus' local variable is not used,
so remove it for clean-up.
Signed-off-by: Austin Kim <austindh.kim@gmail.com>
---
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
index 54a3aec..22441dd 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.c
@@ -485,15 +485,12 @@ bool rtl8723e_phy_config_rf_with_headerfile(struct ieee80211_hw *hw,
enum radio_path rfpath)
{
int i;
- bool rtstatus = true;
u32 *radioa_array_table;
u16 radioa_arraylen;
radioa_arraylen = RTL8723ERADIOA_1TARRAYLENGTH;
radioa_array_table = RTL8723E_RADIOA_1TARRAY;
- rtstatus = true;
-
switch (rfpath) {
case RF90_PATH_A:
for (i = 0; i < radioa_arraylen; i = i + 2) {
--
2.6.2
^ permalink raw reply related
* Re: [PATCH] ath9k: remove unneeded variable
From: Kalle Valo @ 2019-09-17 6:41 UTC (permalink / raw)
To: Ding Xiang; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <1568109312-13175-1-git-send-email-dingxiang@cmss.chinamobile.com>
Ding Xiang <dingxiang@cmss.chinamobile.com> wrote:
> "len" is unneeded,just return 0
>
> Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
ALWAYS build check your patches! I admit that ATH_DUMP_BTCOEX() is an
evil macro as it uses len variable in secret, but if you had compiled
your patch you would have noticed this immeadiately.
In file included from drivers/net/wireless/ath/ath9k/gpio.c:17:
drivers/net/wireless/ath/ath9k/gpio.c: In function 'ath9k_dump_legacy_btcoex':
drivers/net/wireless/ath/ath9k/ath9k.h:763:3: error: 'len' undeclared (first use in this function); did you mean '_end'?
len += scnprintf(buf + len, size - len, \
^~~
drivers/net/wireless/ath/ath9k/gpio.c:502:2: note: in expansion of macro 'ATH_DUMP_BTCOEX'
ATH_DUMP_BTCOEX("Stomp Type", btcoex->bt_stomp_type);
^~~~~~~~~~~~~~~
drivers/net/wireless/ath/ath9k/ath9k.h:763:3: note: each undeclared identifier is reported only once for each function it appears in
len += scnprintf(buf + len, size - len, \
^~~
drivers/net/wireless/ath/ath9k/gpio.c:502:2: note: in expansion of macro 'ATH_DUMP_BTCOEX'
ATH_DUMP_BTCOEX("Stomp Type", btcoex->bt_stomp_type);
^~~~~~~~~~~~~~~
make[5]: *** [drivers/net/wireless/ath/ath9k/gpio.o] Error 1
make[4]: *** [drivers/net/wireless/ath/ath9k] Error 2
make[3]: *** [drivers/net/wireless/ath] Error 2
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
--
https://patchwork.kernel.org/patch/11139147/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Kalle Valo @ 2019-09-17 6:28 UTC (permalink / raw)
To: Chris Chiu
Cc: Jes Sorensen, David Miller, linux-wireless, netdev, Linux Kernel,
Linux Upstreaming Team, Daniel Drake
In-Reply-To: <CAB4CAweWoFuXPci5Re6sdN_kB0i4DkpsYxux+GAHyRHWhC+hhA@mail.gmail.com>
Chris Chiu <chiu@endlessm.com> writes:
> On Mon, Aug 12, 2019 at 11:21 PM Jes Sorensen <jes.sorensen@gmail.com> wrote:
>>
>> On 8/12/19 10:32 AM, Kalle Valo wrote:
>> >> Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
>> >
>> > This is marked as RFC so I'm not sure what's the plan. Should I apply
>> > this?
>>
>> I think it's at a point where it's worth applying - I kinda wish I had
>> had time to test it, but I won't be near my stash of USB dongles for a
>> little while.
>>
>> Cheers,
>> Jes
>>
>
> Gentle ping. Any suggestions for the next step?
Please resubmit without the RFC label.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Fw: [Bug 204879] New: "invalid inflight", WARNING: CPU: 1 PID: 5103 at net/ipv4/tcp_output.c:2509 tcp_send_loss_probe.cold.42+0x20/0x2d
From: Stephen Hemminger @ 2019-09-17 6:09 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Mon, 16 Sep 2019 20:28:15 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 204879] New: "invalid inflight", WARNING: CPU: 1 PID: 5103 at net/ipv4/tcp_output.c:2509 tcp_send_loss_probe.cold.42+0x20/0x2d
https://bugzilla.kernel.org/show_bug.cgi?id=204879
Bug ID: 204879
Summary: "invalid inflight", WARNING: CPU: 1 PID: 5103 at
net/ipv4/tcp_output.c:2509
tcp_send_loss_probe.cold.42+0x20/0x2d
Product: Networking
Version: 2.5
Kernel Version: 4.14.143
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: rm+bko@romanrm.net
Regression: No
After upgrading my kernel version from 4.14.121 to 4.14.143, on every boot I
now get the following warning.
Moreover, eventually (in a few hours) the server appears to lock-up. However I
can't say for sure if the lock-up is related, or what messages appear during
that time, as this is a remote system with no IPMI or the like. There's nothing
in disk-based logs. I'll try netconsole later if this continues to repeat.
For now, any ideas about this particular backtrace? Thanks
[ 35.587989] invalid inflight: 1 state 1 cwnd 14 mss 1428
[ 35.588004] ------------[ cut here ]------------
[ 35.588009] WARNING: CPU: 1 PID: 5103 at net/ipv4/tcp_output.c:2509
tcp_send_loss_probe.cold.42+0x20/0x2d
[ 35.588011] Modules linked in: wireguard ip6_udp_tunnel udp_tunnel
xt_comment xt_u32 xt_connlimit ip6t_MASQUERADE nf_nat_masquerade_ipv6 xt_TCPMSS
xt_nat xt_mark ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_tcpudp xt_set
ip_set_hash_net ip_set nfnetlink xt_multiport xt_limit xt_length xt_conntrack
ip6t_rpfilter ipt_rpfilter ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_raw ip6table_mangle iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_raw iptable_mangle
ip6table_filter ip6_tables iptable_filter ip_tables x_tables
cpufreq_conservative cpufreq_powersave cpufreq_userspace tcp_bbr sch_fq
tcp_illinois intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp
kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc
aesni_intel
[ 35.588042] aes_x86_64 crypto_simd glue_helper cryptd snd_hda_codec_hdmi
intel_cstate snd_hda_codec_realtek snd_hda_codec_generic intel_uncore
snd_hda_intel i915 video iTCO_wdt intel_rapl_perf iTCO_vendor_support
snd_hda_codec drm_kms_helper evdev snd_hda_core pcspkr snd_hwdep snd_pcm
snd_timer pcc_cpufreq mei_me mei drm sg snd shpchp lpc_ich button i2c_algo_bit
serio_raw mfd_core soundcore ext4 crc16 mbcache jbd2 fscrypto btrfs
zstd_decompress zstd_compress xxhash sata_nv dm_crypt raid456 async_raid6_recov
async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic
raid0 raid1 md_mod dm_mirror dm_region_hash dm_log dm_mod ata_piix sd_mod
xhci_pci xhci_hcd crc32c_intel ahci libahci i2c_i801 ehci_pci libata psmouse
ehci_hcd scsi_mod e1000e ptp usbcore pps_core
[ 35.588086] CPU: 1 PID: 5103 Comm: xmrig Not tainted 4.14.144-rm1+ #64
[ 35.588088] Hardware name: /DH67BL, BIOS BLH6710H.86A.0160.2012.1204.1156
12/04/2012
[ 35.588090] task: ffff8e0c0578bb80 task.stack: ffffa6a349524000
[ 35.588093] RIP: 0010:tcp_send_loss_probe.cold.42+0x20/0x2d
[ 35.588095] RSP: 0000:ffff8e0c1f283e70 EFLAGS: 00010246
[ 35.588097] RAX: 000000000000002c RBX: ffff8e0c0b932a80 RCX:
0000000000000000
[ 35.588099] RDX: 0000000000000000 RSI: ffff8e0c1f296738 RDI:
ffff8e0c1f296738
[ 35.588101] RBP: ffff8e0c0b932bd8 R08: 0000000000000000 R09:
0000000000000275
[ 35.588103] R10: ffff8e0c0e911280 R11: 0000000000000000 R12:
ffff8e0c0b932bd8
[ 35.588105] R13: ffffffff827d46b0 R14: ffff8e0c0b932a80 R15:
ffff8e0c1f283ef0
[ 35.588107] FS: 00007f71de376700(0000) GS:ffff8e0c1f280000(0000)
knlGS:0000000000000000
[ 35.588110] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 35.588112] CR2: 000055f0f061c000 CR3: 0000000409d0e001 CR4:
00000000000606e0
[ 35.588114] Call Trace:
[ 35.588116] <IRQ>
[ 35.588120] tcp_write_timer_handler+0xce/0x210
[ 35.588123] tcp_write_timer+0x77/0x90
[ 35.588126] call_timer_fn+0x30/0x130
[ 35.588129] run_timer_softirq+0x3d3/0x410
[ 35.588133] ? timerqueue_add+0x52/0x80
[ 35.588136] ? enqueue_hrtimer+0x36/0x80
[ 35.588140] __do_softirq+0xdb/0x2d5
[ 35.588142] ? hrtimer_interrupt+0x113/0x1d0
[ 35.588147] irq_exit+0xbc/0xd0
[ 35.588150] smp_apic_timer_interrupt+0x78/0x140
[ 35.588152] apic_timer_interrupt+0x85/0x90
[ 35.588154] </IRQ>
[ 35.588156] RIP: 0033:0x7f71ddb3b16f
[ 35.588158] RSP: 002b:81244f1f4aebe662 EFLAGS: 00000206 ORIG_RAX:
ffffffffffffff10
[ 35.588161] RAX: 000000005590220e RBX: 000000004520e100 RCX:
00007f71dd513600
[ 35.588163] RDX: 000000005476b198 RSI: 8219664b28bc2fe0 RDI:
00000000555b6ee0
[ 35.588165] RBP: 0000000092e54880 R08: 000000000007be43 R09:
00000000ce690f4f
[ 35.588166] R10: 00000000001f6970 R11: 00007f71dd400000 R12:
80ee3d8c155f6970
[ 35.588168] R13: 4b3017ab1f4489c9 R14: 3854bb60406a6bea R15:
eb98349c9e84f39a
[ 35.588171] Code: 00 c6 83 7b 04 00 00 00 5b 5d c3 0f b6 53 12 8b 8b 2c 06
00 00 41 89 c0 48 c7 c7 90 e3 06 83 c6 05 39 64 b1 00 01 e8 cd a3 b0 ff <0f> 0b
e9 1f ee ff ff 90 90 90 90 90 90 66 66 66 66 90 48 8b 47
[ 35.588193] ---[ end trace 7c7f3665018c9e60 ]---
--
You are receiving this mail because:
You are the assignee for the bug.
^ 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