* 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: 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: [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: [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
* [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: 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
* 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
* [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 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
* 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 3/5] mdev: Expose mdev alias in sysfs tree
From: Cornelia Huck @ 2019-09-17 10:08 UTC (permalink / raw)
To: Parav Pandit
Cc: alex.williamson, jiri, kwankhede, davem, kvm, linux-kernel,
netdev
In-Reply-To: <20190902042436.23294-4-parav@mellanox.com>
On Sun, 1 Sep 2019 23:24:34 -0500
Parav Pandit <parav@mellanox.com> wrote:
> Expose the optional alias for an mdev device as a sysfs attribute.
> This way, userspace tools such as udev may make use of the alias, for
> example to create a netdevice name for the mdev.
>
> Updated documentation for optional read only sysfs attribute.
>
> Signed-off-by: Parav Pandit <parav@mellanox.com>
>
> ---
> Changelog:
> v2->v3:
> - Merged sysfs documentation patch with sysfs addition
> - Added more description for alias return value
> v0->v1:
> - Addressed comments from Cornelia Huck
> - Updated commit description
> ---
> Documentation/driver-api/vfio-mediated-device.rst | 9 +++++++++
> drivers/vfio/mdev/mdev_sysfs.c | 13 +++++++++++++
> 2 files changed, 22 insertions(+)
>
(...)
> @@ -281,6 +282,14 @@ Example::
>
> # echo 1 > /sys/bus/mdev/devices/$mdev_UUID/remove
>
> +* alias (read only, optional)
> +Whenever a parent requested to generate an alias, each mdev device of such
s/such/that/
> +parent is assigned unique alias by the mdev core.
s/unique alias/a unique alias/
> +This file shows the alias of the mdev device.
> +
> +Reading file either returns valid alias when assigned or returns error code
s/file/this file/
s/valid alias/a valid alias/
s/error code/the error code/
> +-EOPNOTSUPP when unsupported.
> +
> Mediated device Hot plug
> ------------------------
With the nits above fixed,
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* Re: [PATCH v3 4/5] mdev: Introduce an API mdev_alias
From: Cornelia Huck @ 2019-09-17 10:10 UTC (permalink / raw)
To: Parav Pandit
Cc: alex.williamson, jiri, kwankhede, davem, kvm, linux-kernel,
netdev
In-Reply-To: <20190902042436.23294-5-parav@mellanox.com>
On Sun, 1 Sep 2019 23:24:35 -0500
Parav Pandit <parav@mellanox.com> wrote:
> Introduce an API mdev_alias() to provide access to optionally generated
> alias.
>
> Signed-off-by: Parav Pandit <parav@mellanox.com>
> ---
> drivers/vfio/mdev/mdev_core.c | 12 ++++++++++++
> include/linux/mdev.h | 1 +
> 2 files changed, 13 insertions(+)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* RE: [PATCH] net: stmmac: Fix ASSERT_RTNL() warning on suspend/resume
From: Jose Abreu @ 2019-09-17 10:12 UTC (permalink / raw)
To: Loys Ollivier, Russell King, Maxime Coquelin
Cc: David S. Miller, Giuseppe Cavallaro, Alexandre Torgue,
netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1568714556-25024-1-git-send-email-lollivier@baylibre.com>
From: Loys Ollivier <lollivier@baylibre.com>
Date: Sep/17/2019, 11:02:36 (UTC+00:00)
> 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>
I already sent a fix for this. Please see in -net:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/driv
ers/net/ethernet/stmicro/stmmac?id=19e13cb27b998ff49f07e399b5871bfe5ba7e3
f0
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH v3 0/5] Introduce variable length mdev alias
From: Cornelia Huck @ 2019-09-17 10:13 UTC (permalink / raw)
To: Parav Pandit
Cc: alex.williamson, jiri, kwankhede, davem, kvm, linux-kernel,
netdev
In-Reply-To: <20190902042436.23294-1-parav@mellanox.com>
On Sun, 1 Sep 2019 23:24:31 -0500
Parav Pandit <parav@mellanox.com> wrote:
> To have consistent naming for the netdevice of a mdev and to have
> consistent naming of the devlink port [1] of a mdev, which is formed using
> phys_port_name of the devlink port, current UUID is not usable because
> UUID is too long.
>
> UUID in string format is 36-characters long and in binary 128-bit.
> Both formats are not able to fit within 15 characters limit of netdev
> name.
>
> It is desired to have mdev device naming consistent using UUID.
> So that widely used user space framework such as ovs [2] can make use
> of mdev representor in similar way as PCIe SR-IOV VF and PF representors.
>
> Hence,
> (a) mdev alias is created which is derived using sha1 from the mdev name.
> (b) Vendor driver describes how long an alias should be for the child mdev
> created for a given parent.
> (c) Mdev aliases are unique at system level.
> (d) alias is created optionally whenever parent requested.
> This ensures that non networking mdev parents can function without alias
> creation overhead.
>
> This design is discussed at [3].
>
> An example systemd/udev extension will have,
>
> 1. netdev name created using mdev alias available in sysfs.
>
> mdev UUID=83b8f4f2-509f-382f-3c1e-e6bfe0fa1001
> mdev 12 character alias=cd5b146a80a5
>
> netdev name of this mdev = enmcd5b146a80a5
> Here en = Ethernet link
> m = mediated device
>
> 2. devlink port phys_port_name created using mdev alias.
> devlink phys_port_name=pcd5b146a80a5
>
> This patchset enables mdev core to maintain unique alias for a mdev.
>
> Patch-1 Introduces mdev alias using sha1.
> Patch-2 Ensures that mdev alias is unique in a system.
> Patch-3 Exposes mdev alias in a sysfs hirerchy, update Documentation
> Patch-4 Introduces mdev_alias() API.
> Patch-5 Extends mtty driver to optionally provide alias generation.
> This also enables to test UUID based sha1 collision and trigger
> error handling for duplicate sha1 results.
>
> [1] http://man7.org/linux/man-pages/man8/devlink-port.8.html
> [2] https://docs.openstack.org/os-vif/latest/user/plugins/ovs.html
> [3] https://patchwork.kernel.org/cover/11084231/
>
> ---
> Changelog:
> v2->v3:
> - Addressed comment from Yunsheng Lin
> - Changed strcmp() ==0 to !strcmp()
> - Addressed comment from Cornelia Hunk
> - Merged sysfs Documentation patch with syfs patch
> - Added more description for alias return value
> v1->v2:
> - Corrected a typo from 'and' to 'an'
> - Addressed comments from Alex Williamson
> - Kept mdev_device naturally aligned
> - Added error checking for crypt_*() calls
> - Moved alias NULL check at beginning
> - Added mdev_alias() API
> - Updated mtty driver to show example mdev_alias() usage
> - Changed return type of generate_alias() from int to char*
> v0->v1:
> - Addressed comments from Alex Williamson, Cornelia Hunk and Mark Bloch
> - 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
> - Added comment where alias memory ownership is handed over to mdev device
> - Fixed cleaunup of hash if mdev_bus_register() fails
> - Updated documentation for new sysfs alias file
> - Improved commit logs to make description more clear
> - Fixed inclusiong of alias for NULL check
> - Added ratelimited debug print for sha1 hash collision error
>
> Parav Pandit (5):
> mdev: Introduce sha1 based mdev alias
> mdev: Make mdev alias unique among all mdevs
> mdev: Expose mdev alias in sysfs tree
> mdev: Introduce an API mdev_alias
> mtty: Optionally support mtty alias
>
> .../driver-api/vfio-mediated-device.rst | 9 ++
> drivers/vfio/mdev/mdev_core.c | 142 +++++++++++++++++-
> drivers/vfio/mdev/mdev_private.h | 5 +-
> drivers/vfio/mdev/mdev_sysfs.c | 26 +++-
> include/linux/mdev.h | 5 +
> samples/vfio-mdev/mtty.c | 13 ++
> 6 files changed, 190 insertions(+), 10 deletions(-)
>
The patches on their own look sane (and I gave my R-b), but the
consumer of this new API should be ready before this is merged, as
already discussed below.
^ permalink raw reply
* Re: [PATCH v3 bpf-next 09/14] samples: bpf: makefile: use own flags but not host when cross compile
From: Sergei Shtylyov @ 2019-09-17 10:14 UTC (permalink / raw)
To: Ivan Khoronzhuk, ast, daniel, yhs, davem, jakub.kicinski, hawk,
john.fastabend
Cc: linux-kernel, netdev, bpf, clang-built-linux
In-Reply-To: <20190916105433.11404-10-ivan.khoronzhuk@linaro.org>
Hello!
On 16.09.2019 13:54, Ivan Khoronzhuk wrote:
> While compile natively, the hosts cflags and ldflags are equal to ones
Compiling. Host's.
> used from HOSTCFLAGS and HOSTLDFLAGS. When cross compiling it should
> have own, used for target arch. While verification, for arm, arm64 and
> x86_64 the following flags were used alsways:
>
> -Wall
> -O2
> -fomit-frame-pointer
> -Wmissing-prototypes
> -Wstrict-prototypes
>
> So, add them as they were verified and used before adding
> Makefile.target, but anyway limit it only for cross compile options as
> for host can be some configurations when another options can be used,
> So, for host arch samples left all as is, it allows to avoid potential
> option mistmatches for existent environments.
Mismatches.
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
[...]
MBR, Sergei
^ permalink raw reply
* RE: -Wsizeof-array-div warnings in ethernet drivers
From: David Laight @ 2019-09-17 10:36 UTC (permalink / raw)
To: 'Jose Abreu', 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: <BN8PR12MB3266AFAFF3FAAA9C10FB1C1FD38F0@BN8PR12MB3266.namprd12.prod.outlook.com>
From: Jose Abreu
> Sent: 17 September 2019 08:59
> 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:
...
> > ../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);
> > ~~~~~~~~~~~~~~ ^
...
> > 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.
That stinks of a possible misaligned data access.....
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH bpf-next] i40e: fix xdp handle calculations
From: Maxim Mikityanskiy @ 2019-09-17 10:48 UTC (permalink / raw)
To: Kevin Laatz, bjorn.topel
Cc: maximmi, netdev, ast, daniel, magnus.karlsson, jonathan.lemon,
bruce.richardson, ciara.loftus, bpf, intel-wired-lan
In-Reply-To: <20190905011144.3513-1-kevin.laatz@intel.com>
On Thu, Sep 5, 2019 at 4:11 AM Kevin Laatz <kevin.laatz@intel.com> wrote:
>
> Currently, we don't add headroom to the handle in i40e_zca_free,
> i40e_alloc_buffer_slow_zc and i40e_alloc_buffer_zc. The addition of the
> headroom to the handle was removed in
> commit 2f86c806a8a8 ("i40e: modify driver for handling offsets"),
Hi, it looks to me that headroom is still broken after this commit.
i40e_run_xdp_zc adds it a second time, i.e.:
1. xdp->handle already has the headroom added (after this patch).
2. bpf_prog_run_xdp(...);
3. u64 offset = umem->headroom;
offset += xdp->data - xdp->data_hard_start;
xdp->handle = xsk_umem_adjust_offset(umem, xdp->handle, offset);
Step 3 adds the headroom one extra time.
I didn't look at ixgbe, it might also need to be fixed.
> which
> will break things when headroom is non-zero. This patch fixes this and uses
> xsk_umem_adjust_offset to add it appropritely based on the mode being run.
>
> Fixes: 2f86c806a8a8 ("i40e: modify driver for handling offsets")
> Reported-by: Bjorn Topel <bjorn.topel@intel.com>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> Acked-by: Björn Töpel <bjorn.topel@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_xsk.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.c b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> index eaca6162a6e6..0373bc6c7e61 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> @@ -267,7 +267,7 @@ static bool i40e_alloc_buffer_zc(struct i40e_ring *rx_ring,
> bi->addr = xdp_umem_get_data(umem, handle);
> bi->addr += hr;
>
> - bi->handle = handle;
> + bi->handle = xsk_umem_adjust_offset(umem, handle, umem->headroom);
>
> xsk_umem_discard_addr(umem);
> return true;
> @@ -304,7 +304,7 @@ static bool i40e_alloc_buffer_slow_zc(struct i40e_ring *rx_ring,
> bi->addr = xdp_umem_get_data(umem, handle);
> bi->addr += hr;
>
> - bi->handle = handle;
> + bi->handle = xsk_umem_adjust_offset(umem, handle, umem->headroom);
>
> xsk_umem_discard_addr_rq(umem);
> return true;
> @@ -469,7 +469,8 @@ void i40e_zca_free(struct zero_copy_allocator *alloc, unsigned long handle)
> bi->addr = xdp_umem_get_data(rx_ring->xsk_umem, handle);
> bi->addr += hr;
>
> - bi->handle = (u64)handle;
> + bi->handle = xsk_umem_adjust_offset(rx_ring->xsk_umem, (u64)handle,
> + rx_ring->xsk_umem->headroom);
> }
>
> /**
^ permalink raw reply
* Re: [PATCH bpf-next] i40e: fix xdp handle calculations
From: Björn Töpel @ 2019-09-17 10:54 UTC (permalink / raw)
To: Maxim Mikityanskiy, Kevin Laatz
Cc: maximmi, netdev, ast, daniel, magnus.karlsson, jonathan.lemon,
bruce.richardson, ciara.loftus, bpf, intel-wired-lan
In-Reply-To: <CAKErNvpe3htU-ETe0y0XQ=SwY047qc3Z3=aHN6g2BbkoGHNNUQ@mail.gmail.com>
On 2019-09-17 12:48, Maxim Mikityanskiy wrote:
> Hi, it looks to me that headroom is still broken after this commit.
> i40e_run_xdp_zc adds it a second time, i.e.:
Indeed, but Ciara fixed that in this series [1]. Thanks for reviewing
the patch!
Cheers,
Björn
[1]
https://lore.kernel.org/bpf/20190913103948.32053-1-ciara.loftus@intel.com/
^ permalink raw reply
* Re: [PATCH v7 6/7] nfc: pn533: Add autopoll capability
From: Lars Poeschel @ 2019-09-17 10:55 UTC (permalink / raw)
To: David Miller
Cc: allison, keescook, opensource, swinslow, gregkh, gustavo, tglx,
kstewart, netdev, linux-kernel, johan
In-Reply-To: <20190911.101759.1557703938346599792.davem@davemloft.net>
On Wed, Sep 11, 2019 at 10:17:59AM +0200, David Miller wrote:
> From: Lars Poeschel <poeschel@lemonage.de>
> Date: Tue, 10 Sep 2019 11:34:12 +0200
>
> > +static int pn533_autopoll_complete(struct pn533 *dev, void *arg,
> > + struct sk_buff *resp)
> > +{
> > + u8 nbtg;
> > + int rc;
> > + struct pn532_autopoll_resp *apr;
> > + struct nfc_target nfc_tgt;
>
> Need reverse christmas tree here.
See below.
> > @@ -1534,6 +1655,7 @@ static int pn533_start_poll(struct nfc_dev *nfc_dev,
> > struct pn533_poll_modulations *cur_mod;
> > u8 rand_mod;
> > int rc;
> > + struct sk_buff *skb;
>
> Likewise.
I will do a v8 with these changes soon.
^ permalink raw reply
* Re: [PATCH v7 5/7] nfc: pn533: add UART phy driver
From: Lars Poeschel @ 2019-09-17 10:56 UTC (permalink / raw)
To: David Miller
Cc: gregkh, tglx, kstewart, swinslow, allison, linux-kernel, netdev,
johan, Claudiu.Beznea
In-Reply-To: <20190911.101732.1453519960272118746.davem@davemloft.net>
On Wed, Sep 11, 2019 at 10:17:32AM +0200, David Miller wrote:
> From: Lars Poeschel <poeschel@lemonage.de>
> Date: Tue, 10 Sep 2019 11:33:50 +0200
>
> > +static int pn532_uart_send_ack(struct pn533 *dev, gfp_t flags)
> > +{
> > + struct pn532_uart_phy *pn532 = dev->phy;
> > + /* spec 7.1.1.3: Preamble, SoPC (2), ACK Code (2), Postamble */
> > + static const u8 ack[PN533_STD_FRAME_ACK_SIZE] = {
> > + 0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
> > + int err;
>
> Reverse christmas tree ordering for the local variables please.
See below.
> > +static int pn532_uart_rx_is_frame(struct sk_buff *skb)
> > +{
> > + int i;
> > + u16 frame_len;
> > + struct pn533_std_frame *std;
> > + struct pn533_ext_frame *ext;
>
> Likewise.
Ok, I will do a v8 soon with these changes.
^ permalink raw reply
* Re: [RFC v4 0/3] vhost: introduce mdev based hardware backend
From: Tiwei Bie @ 2019-09-17 10:58 UTC (permalink / raw)
To: Jason Wang
Cc: mst, alex.williamson, maxime.coquelin, linux-kernel, kvm,
virtualization, netdev, dan.daly, cunming.liang, zhihong.wang,
lingshan.zhu
In-Reply-To: <993841ed-942e-c90b-8016-8e7dc76bf13a@redhat.com>
On Tue, Sep 17, 2019 at 11:32:03AM +0800, Jason Wang wrote:
> On 2019/9/17 上午9:02, Tiwei Bie wrote:
> > This RFC is to demonstrate below ideas,
> >
> > a) Build vhost-mdev on top of the same abstraction defined in
> > the virtio-mdev series [1];
> >
> > b) Introduce /dev/vhost-mdev to do vhost ioctls and support
> > setting mdev device as backend;
> >
> > Now the userspace API looks like this:
> >
> > - Userspace generates a compatible mdev device;
> >
> > - Userspace opens this mdev device with VFIO API (including
> > doing IOMMU programming for this mdev device with VFIO's
> > container/group based interface);
> >
> > - Userspace opens /dev/vhost-mdev and gets vhost fd;
> >
> > - Userspace uses vhost ioctls to setup vhost (userspace should
> > do VHOST_MDEV_SET_BACKEND ioctl with VFIO group fd and device
> > fd first before doing other vhost ioctls);
> >
> > Only compile test has been done for this series for now.
>
>
> Have a hard thought on the architecture:
Thanks a lot! Do appreciate it!
>
> 1) Create a vhost char device and pass vfio mdev device fd to it as a
> backend and translate vhost-mdev ioctl to virtio mdev transport (e.g
> read/write). DMA was done through the VFIO DMA mapping on the container that
> is attached.
Yeah, that's what we are doing in this series.
>
> We have two more choices:
>
> 2) Use vfio-mdev but do not create vhost-mdev device, instead, just
> implement vhost ioctl on vfio_device_ops, and translate them into
> virtio-mdev transport or just pass ioctl to parent.
Yeah. Instead of introducing /dev/vhost-mdev char device, do
vhost ioctls on VFIO device fd directly. That's what we did
in RFC v3.
>
> 3) Don't use vfio-mdev, create a new vhost-mdev driver, during probe still
> try to add dev to vfio group and talk to parent with device specific ops
If my understanding is correct, this means we need to introduce
a new VFIO device driver to replace the existing vfio-mdev driver
in our case. Below is a quick draft just to show my understanding:
#include <linux/init.h>
#include <linux/module.h>
#include <linux/device.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/vfio.h>
#include <linux/mdev.h>
#include "mdev_private.h"
/* XXX: we need a proper way to include below vhost header. */
#include "../../vhost/vhost.h"
static int vfio_vhost_mdev_open(void *device_data)
{
if (!try_module_get(THIS_MODULE))
return -ENODEV;
/* ... */
vhost_dev_init(...);
return 0;
}
static void vfio_vhost_mdev_release(void *device_data)
{
/* ... */
module_put(THIS_MODULE);
}
static long vfio_vhost_mdev_unlocked_ioctl(void *device_data,
unsigned int cmd, unsigned long arg)
{
struct mdev_device *mdev = device_data;
struct mdev_parent *parent = mdev->parent;
/*
* Use vhost ioctls.
*
* We will have a different parent_ops design.
* And potentially, we can share the same parent_ops
* with virtio_mdev.
*/
switch (cmd) {
case VHOST_GET_FEATURES:
parent->ops->get_features(mdev, ...);
break;
/* ... */
}
return 0;
}
static ssize_t vfio_vhost_mdev_read(void *device_data, char __user *buf,
size_t count, loff_t *ppos)
{
/* ... */
return 0;
}
static ssize_t vfio_vhost_mdev_write(void *device_data, const char __user *buf,
size_t count, loff_t *ppos)
{
/* ... */
return 0;
}
static int vfio_vhost_mdev_mmap(void *device_data, struct vm_area_struct *vma)
{
/* ... */
return 0;
}
static const struct vfio_device_ops vfio_vhost_mdev_dev_ops = {
.name = "vfio-vhost-mdev",
.open = vfio_vhost_mdev_open,
.release = vfio_vhost_mdev_release,
.ioctl = vfio_vhost_mdev_unlocked_ioctl,
.read = vfio_vhost_mdev_read,
.write = vfio_vhost_mdev_write,
.mmap = vfio_vhost_mdev_mmap,
};
static int vfio_vhost_mdev_probe(struct device *dev)
{
struct mdev_device *mdev = to_mdev_device(dev);
/* ... */
return vfio_add_group_dev(dev, &vfio_vhost_mdev_dev_ops, mdev);
}
static void vfio_vhost_mdev_remove(struct device *dev)
{
/* ... */
vfio_del_group_dev(dev);
}
static struct mdev_driver vfio_vhost_mdev_driver = {
.name = "vfio_vhost_mdev",
.probe = vfio_vhost_mdev_probe,
.remove = vfio_vhost_mdev_remove,
};
static int __init vfio_vhost_mdev_init(void)
{
return mdev_register_driver(&vfio_vhost_mdev_driver, THIS_MODULE);
}
module_init(vfio_vhost_mdev_init)
static void __exit vfio_vhost_mdev_exit(void)
{
mdev_unregister_driver(&vfio_vhost_mdev_driver);
}
module_exit(vfio_vhost_mdev_exit)
>
> So I have some questions:
>
> 1) Compared to method 2, what's the advantage of creating a new vhost char
> device? I guess it's for keep the API compatibility?
One benefit is that we can avoid doing vhost ioctls on
VFIO device fd.
>
> 2) For method 2, is there any easy way for user/admin to distinguish e.g
> ordinary vfio-mdev for vhost from ordinary vfio-mdev?
I think device-api could be a choice.
> I saw you introduce
> ops matching helper but it's not friendly to management.
The ops matching helper is just to check whether a given
vfio-device is based on a mdev device.
>
> 3) A drawback of 1) and 2) is that it must follow vfio_device_ops that
> assumes the parameter comes from userspace, it prevents support kernel
> virtio drivers.
>
> 4) So comes the idea of method 3, since it register a new vhost-mdev driver,
> we can use device specific ops instead of VFIO ones, then we can have a
> common API between vDPA parent and vhost-mdev/virtio-mdev drivers.
As the above draft shows, this requires introducing a new
VFIO device driver. I think Alex's opinion matters here.
Thanks,
Tiwei
>
> What's your thoughts?
>
> Thanks
>
>
> >
> > RFCv3: https://patchwork.kernel.org/patch/11117785/
> >
> > [1] https://lkml.org/lkml/2019/9/10/135
> >
> > Tiwei Bie (3):
> > vfio: support getting vfio device from device fd
> > vfio: support checking vfio driver by device ops
> > vhost: introduce mdev based hardware backend
> >
> > drivers/vfio/mdev/vfio_mdev.c | 3 +-
> > drivers/vfio/vfio.c | 32 +++
> > drivers/vhost/Kconfig | 9 +
> > drivers/vhost/Makefile | 3 +
> > drivers/vhost/mdev.c | 462 +++++++++++++++++++++++++++++++
> > drivers/vhost/vhost.c | 39 ++-
> > drivers/vhost/vhost.h | 6 +
> > include/linux/vfio.h | 11 +
> > include/uapi/linux/vhost.h | 10 +
> > include/uapi/linux/vhost_types.h | 5 +
> > 10 files changed, 573 insertions(+), 7 deletions(-)
> > create mode 100644 drivers/vhost/mdev.c
> >
^ permalink raw reply
* Re: divide error in usbnet_update_max_qlen
From: Oliver Neukum @ 2019-09-17 11:22 UTC (permalink / raw)
To: syzbot, davem, andreyknvl, syzkaller-bugs, linux-kernel,
linux-usb, netdev
In-Reply-To: <000000000000b83b550592ab965b@google.com>
[-- Attachment #1: Type: text/plain, Size: 889 bytes --]
Am Montag, den 16.09.2019, 06:29 -0700 schrieb syzbot:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: f0df5c1b usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=117659fa600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=5c6633fa4ed00be5
> dashboard link: https://syzkaller.appspot.com/bug?extid=6102c120be558c885f04
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12107ba9600000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=146014e6600000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6102c120be558c885f04@syzkaller.appspotmail.com
#syz test: https://github.com/google/kasan.git f0df5c1b
[-- Attachment #2: 0001-usbnet-sanity-checking-of-packet-sizes.patch --]
[-- Type: text/x-patch, Size: 1073 bytes --]
From 57c2443b2a7678a6f7f6437f741f49f06a5104fb Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Tue, 17 Sep 2019 11:51:55 +0200
Subject: [PATCH] usbnet: sanity checking of packet sizes
Malicious devices can set this to zero and we divide by it.
Introduce sanity checking.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
drivers/net/usb/usbnet.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 58952a79b05f..e44849499b89 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -339,6 +339,8 @@ void usbnet_update_max_qlen(struct usbnet *dev)
{
enum usb_device_speed speed = dev->udev->speed;
+ if (!dev->rx_urb_size || !dev->hard_mtu)
+ goto insanity;
switch (speed) {
case USB_SPEED_HIGH:
dev->rx_qlen = MAX_QUEUE_MEMORY / dev->rx_urb_size;
@@ -355,6 +357,7 @@ void usbnet_update_max_qlen(struct usbnet *dev)
dev->tx_qlen = 5 * MAX_QUEUE_MEMORY / dev->hard_mtu;
break;
default:
+insanity:
dev->rx_qlen = dev->tx_qlen = 4;
}
}
--
2.16.4
^ permalink raw reply related
* [RFC PATCH v2 0/6] Enable ptp_kvm for arm64
From: Jianyong Wu @ 2019-09-17 11:24 UTC (permalink / raw)
To: netdev, pbonzini, sean.j.christopherson, maz, richardcochran,
Mark.Rutland, Will.Deacon, suzuki.poulose
Cc: linux-kernel, Steve.Capper, Kaly.Xin, justin.he, jianyong.wu, nd,
linux-arm-kernel
kvm ptp targets to provide high precision time sync between guest
and host in virtualization environment. This patch enable kvm ptp
for arm64.
This patch set base on [1][2][3]
change log:
from v1 to v2:
(1) move arch-specific code from arch/ to driver/ptp/
(2) offer mechanism to inform userspace if ptp_kvm service is
available.
(3) separate ptp_kvm code for arm64 into hypervisor part and
guest part.
(4) add API to expose monotonic clock and counter value.
(5) refine code: remove no necessary part and reconsitution.
[1]https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/
commit/?h=kvm/hvc&id=125ea89e4a21e2fc5235410f966a996a1a7148bf
[2]https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/
commit/?h=kvm/hvc&id=464f5a1741e5959c3e4d2be1966ae0093b4dce06
[3]https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/
commit/?h=kvm/hvc&id=6597490e005d0eeca8ed8c1c1d7b4318ee014681
Jianyong Wu (6):
Export psci_ops.conduit symbol as modules will use it.
reorganize ptp_kvm modules to make it arch-independent.
Timer: expose monotonic clock and counter value
arm64: Add hvc call service for ptp_kvm.
Enable ptp_kvm for arm64
kvm: add kvm ptp capability extension for arm64
drivers/firmware/psci/psci.c | 6 ++
drivers/ptp/Kconfig | 2 +-
drivers/ptp/Makefile | 1 +
drivers/ptp/{ptp_kvm.c => kvm_ptp.c} | 77 ++++++------------------
drivers/ptp/ptp_kvm_arm64.c | 82 ++++++++++++++++++++++++++
drivers/ptp/ptp_kvm_x86.c | 87 ++++++++++++++++++++++++++++
include/asm-generic/ptp_kvm.h | 12 ++++
include/linux/arm-smccc.h | 14 ++++-
include/linux/psci.h | 1 +
include/linux/timekeeping.h | 3 +
include/uapi/linux/kvm.h | 1 +
kernel/time/timekeeping.c | 13 +++++
virt/kvm/arm/arm.c | 1 +
virt/kvm/arm/psci.c | 17 ++++++
14 files changed, 256 insertions(+), 61 deletions(-)
rename drivers/ptp/{ptp_kvm.c => kvm_ptp.c} (63%)
create mode 100644 drivers/ptp/ptp_kvm_arm64.c
create mode 100644 drivers/ptp/ptp_kvm_x86.c
create mode 100644 include/asm-generic/ptp_kvm.h
--
2.17.1
^ permalink raw reply
* [PATCH 3/6] Timer: expose monotonic clock and counter value
From: Jianyong Wu @ 2019-09-17 11:24 UTC (permalink / raw)
To: netdev, pbonzini, sean.j.christopherson, maz, richardcochran,
Mark.Rutland, Will.Deacon, suzuki.poulose
Cc: linux-kernel, Steve.Capper, Kaly.Xin, justin.he, jianyong.wu, nd,
linux-arm-kernel
In-Reply-To: <20190917112430.45680-1-jianyong.wu@arm.com>
A number of PTP drivers (such as ptp-kvm) are assuming what the
current clock source is, which could lead to interesting effects on
systems where the clocksource can change depending on external events.
For this purpose, add a new API that retrives both the current
monotonic clock as well as its counter value.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
---
include/linux/timekeeping.h | 3 +++
kernel/time/timekeeping.c | 13 +++++++++++++
2 files changed, 16 insertions(+)
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index a8ab0f143ac4..a5389adaa8bc 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -247,6 +247,9 @@ extern int get_device_system_crosststamp(
struct system_time_snapshot *history,
struct system_device_crosststamp *xtstamp);
+/* Obtain current monotonic clock and its counter value */
+extern void get_current_counterval(struct system_counterval_t *sc);
+
/*
* Simultaneously snapshot realtime and monotonic raw clocks
*/
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 44b726bab4bd..07a0969625b1 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1098,6 +1098,19 @@ static bool cycle_between(u64 before, u64 test, u64 after)
return false;
}
+/**
+ * get_current_counterval - Snapshot the current clocksource and counter value
+ * @sc: Pointer to a struct containing the current clocksource and its value
+ */
+void get_current_counterval(struct system_counterval_t *sc)
+{
+ struct timekeeper *tk = &tk_core.timekeeper;
+
+ sc->cs = READ_ONCE(tk->tkr_mono.clock);
+ sc->cycles = sc->cs->read(sc->cs);
+}
+EXPORT_SYMBOL_GPL(get_current_counterval);
+
/**
* get_device_system_crosststamp - Synchronously capture system/device timestamp
* @get_time_fn: Callback to get simultaneous device time and
--
2.17.1
^ permalink raw reply related
* [RFC PATCH v2 4/6] arm64: Add hvc call service for ptp_kvm.
From: Jianyong Wu @ 2019-09-17 11:24 UTC (permalink / raw)
To: netdev, pbonzini, sean.j.christopherson, maz, richardcochran,
Mark.Rutland, Will.Deacon, suzuki.poulose
Cc: linux-kernel, Steve.Capper, Kaly.Xin, justin.he, jianyong.wu, nd,
linux-arm-kernel
In-Reply-To: <20190917112430.45680-1-jianyong.wu@arm.com>
This patch is the base of ptp_kvm for arm64.
ptp_kvm modules will call hvc to get this service.
The service offers real time and counter cycle of host for guest.
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
---
include/linux/arm-smccc.h | 12 ++++++++++++
virt/kvm/arm/psci.c | 17 +++++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index a6e4d3e3d10a..bc0cdad10f35 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -94,6 +94,7 @@
/* KVM "vendor specific" services */
#define ARM_SMCCC_KVM_FUNC_FEATURES 0
+#define ARM_SMCCC_KVM_PTP 1
#define ARM_SMCCC_KVM_FUNC_FEATURES_2 127
#define ARM_SMCCC_KVM_NUM_FUNCS 128
@@ -103,6 +104,17 @@
ARM_SMCCC_OWNER_VENDOR_HYP, \
ARM_SMCCC_KVM_FUNC_FEATURES)
+/*
+ * This ID used for virtual ptp kvm clock and it will pass second value
+ * and nanosecond value of host real time and system counter by vcpu
+ * register to guest.
+ */
+#define ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_VENDOR_HYP, \
+ ARM_SMCCC_KVM_PTP)
+
#ifndef __ASSEMBLY__
#include <linux/linkage.h>
diff --git a/virt/kvm/arm/psci.c b/virt/kvm/arm/psci.c
index 0debf49bf259..2c5d53817a28 100644
--- a/virt/kvm/arm/psci.c
+++ b/virt/kvm/arm/psci.c
@@ -392,6 +392,8 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
u32 func_id = smccc_get_function(vcpu);
u32 val[4] = {};
u32 option;
+ struct timespec *ts;
+ struct system_counterval_t sc;
val[0] = SMCCC_RET_NOT_SUPPORTED;
@@ -431,6 +433,21 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
break;
+ /*
+ * This will used for virtual ptp kvm clock. three
+ * values will be passed back.
+ * reg0 stores seconds of host real time;
+ * reg1 stores nanoseconds of host real time;
+ * reg2 stores system counter cycle value.
+ */
+ case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
+ getnstimeofday(ts);
+ get_current_counterval(&sc);
+ val[0] = ts->tv_sec;
+ val[1] = ts->tv_nsec;
+ val[2] = sc.cycles;
+ val[3] = 0;
+ break;
default:
return kvm_psci_call(vcpu);
}
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox