* Re: [PATCH mlx5-next v1 2/8] net/mlx5: Add support for flow table destination number
From: Or Gerlitz @ 2018-07-12 21:00 UTC (permalink / raw)
To: Yishai Hadas
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180711111045.6282-3-leon@kernel.org>
On Wed, Jul 11, 2018 at 2:10 PM, Leon Romanovsky <leon@kernel.org> wrote:
> From: Yishai Hadas <yishaih@mellanox.com>
>
> Add support to set a destination from a flow table number.
> This functionality will be used in downstream patches from this
> series by the DEVX stuff.
Reading your cover letter, I still don't understand what is missing in
the current mlx5
fs core API for your needs. After all, you do create flow tables from
the IB driver through
fs core calls, right? so @ the end of the day, you have the FT pointer
to provide the core,
why you need the FT number?
^ permalink raw reply
* Re: [PATCH 00/14] ARM BPF jit compiler improvements
From: Russell King - ARM Linux @ 2018-07-12 21:02 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, linux-arm-kernel
In-Reply-To: <bf534d05-8f75-20bc-e25e-4536c1123585@iogearbox.net>
On Thu, Jul 12, 2018 at 09:02:41PM +0200, Daniel Borkmann wrote:
> Applied to bpf-next, thanks a lot Russell!
Thanks, I've just sent four more patches, which is the sum total of
what I'm intending to send for BPF improvements for the next merge
window.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* Re: WARNING in bpf_check
From: Daniel Borkmann @ 2018-07-12 21:15 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot; +Cc: Alexei Starovoitov, LKML, netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+aDK2yFb=8GGMEL8+Tfq6VVJhU-jrhMrQj9KywmMBNHNg@mail.gmail.com>
On 07/12/2018 09:51 AM, Dmitry Vyukov wrote:
> On Thu, Jul 12, 2018 at 9:41 AM, syzbot
> <syzbot+7d427828b2ea6e592804@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: 671dffa7de7b Merge branch 'bpf-bpftool-improved-prog-load'
>> git tree: bpf-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1550b562400000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=a501a01deaf0fe9
>> dashboard link: https://syzkaller.appspot.com/bug?extid=7d427828b2ea6e592804
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
#syz fix: bpf: don't leave partial mangled prog in jit_subprogs error path
^ permalink raw reply
* Re: [PATCH bpf v2] bpf: don't leave partial mangled prog in jit_subprogs error path
From: Alexei Starovoitov @ 2018-07-12 21:05 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: ast, netdev
In-Reply-To: <20180712194428.12403-1-daniel@iogearbox.net>
On Thu, Jul 12, 2018 at 09:44:28PM +0200, Daniel Borkmann wrote:
> syzkaller managed to trigger the following bug through fault injection:
>
> [...]
> [ 141.043668] verifier bug. No program starts at insn 3
> [ 141.044648] WARNING: CPU: 3 PID: 4072 at kernel/bpf/verifier.c:1613
> get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
> [ 141.044648] WARNING: CPU: 3 PID: 4072 at kernel/bpf/verifier.c:1613
> fixup_call_args kernel/bpf/verifier.c:5587 [inline]
> [ 141.044648] WARNING: CPU: 3 PID: 4072 at kernel/bpf/verifier.c:1613
> bpf_check+0x525e/0x5e60 kernel/bpf/verifier.c:5952
> [ 141.047355] CPU: 3 PID: 4072 Comm: a.out Not tainted 4.18.0-rc4+ #51
> [ 141.048446] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS 1.10.2-1 04/01/2014
> [ 141.049877] Call Trace:
> [ 141.050324] __dump_stack lib/dump_stack.c:77 [inline]
> [ 141.050324] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> [ 141.050950] ? dump_stack_print_info.cold.2+0x52/0x52 lib/dump_stack.c:60
> [ 141.051837] panic+0x238/0x4e7 kernel/panic.c:184
> [ 141.052386] ? add_taint.cold.5+0x16/0x16 kernel/panic.c:385
> [ 141.053101] ? __warn.cold.8+0x148/0x1ba kernel/panic.c:537
> [ 141.053814] ? __warn.cold.8+0x117/0x1ba kernel/panic.c:530
> [ 141.054506] ? get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
> [ 141.054506] ? fixup_call_args kernel/bpf/verifier.c:5587 [inline]
> [ 141.054506] ? bpf_check+0x525e/0x5e60 kernel/bpf/verifier.c:5952
> [ 141.055163] __warn.cold.8+0x163/0x1ba kernel/panic.c:538
> [ 141.055820] ? get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
> [ 141.055820] ? fixup_call_args kernel/bpf/verifier.c:5587 [inline]
> [ 141.055820] ? bpf_check+0x525e/0x5e60 kernel/bpf/verifier.c:5952
> [...]
>
> What happens in jit_subprogs() is that kcalloc() for the subprog func
> buffer is failing with NULL where we then bail out. Latter is a plain
> return -ENOMEM, and this is definitely not okay since earlier in the
> loop we are walking all subprogs and temporarily rewrite insn->off to
> remember the subprog id as well as insn->imm to temporarily point the
> call to __bpf_call_base + 1 for the initial JIT pass. Thus, bailing
> out in such state and handing this over to the interpreter is troublesome
> since later/subsequent e.g. find_subprog() lookups are based on wrong
> insn->imm.
>
> Therefore, once we hit this point, we need to jump to out_free path
> where we undo all changes from earlier loop, so that interpreter can
> work on unmodified insn->{off,imm}.
>
> Another point is that should find_subprog() fail in jit_subprogs() due
> to a verifier bug, then we also should not simply defer the program to
> the interpreter since also here we did partial modifications. Instead
> we should just bail out entirely and return an error to the user who is
> trying to load the program.
>
> Fixes: 1c2a088a6626 ("bpf: x64: add JIT support for multi-function programs")
> Reported-by: syzbot+7d427828b2ea6e592804@syzkaller.appspotmail.com
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Applied, Thanks
^ permalink raw reply
* we do editing for you
From: Simon @ 2018-07-12 11:51 UTC (permalink / raw)
To: netdev
We are a good team, we can process 200+ images each day for you.
If you need any image editing service, please let us know.
Photos cut out; Photos clipping path; Photos masking; Photo shadow
creation; Photos color correction;
Photos retouching; Beauty Model retouching on skin, face, body; Glamour
retouching; Products retouching.
We deliver the work within 24-48 hours.
We can give you editing test on your photos.
Please reply if you have interests.
Our advantages:
Quality is good
Turnaround time fast
7/24/365 available
Thanks,
Simon Nelson
^ permalink raw reply
* Re: [PATCH 00/14] ARM BPF jit compiler improvements
From: Daniel Borkmann @ 2018-07-12 21:12 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: netdev, linux-arm-kernel
In-Reply-To: <20180712210236.GV17271@n2100.armlinux.org.uk>
On 07/12/2018 11:02 PM, Russell King - ARM Linux wrote:
> On Thu, Jul 12, 2018 at 09:02:41PM +0200, Daniel Borkmann wrote:
>> Applied to bpf-next, thanks a lot Russell!
>
> Thanks, I've just sent four more patches, which is the sum total of
> what I'm intending to send for BPF improvements for the next merge
> window.
Great, thanks a lot for the batch of improvements, Russell!
Did you manage to get the BPF kselftest suite working on arm32 under
tools/testing/selftests/bpf/? In particular the test_verfier with
bpf_jit_enabled set to 1 and test_kmod.sh has a bigger number of
runtime tests that would stress it.
Thanks,
Daniel
^ permalink raw reply
* Re: BUG: MAX_LOCK_DEPTH too low! (2)
From: syzbot @ 2018-07-12 21:35 UTC (permalink / raw)
To: davem, e, edumazet, jbenc, linux-kernel, netdev, pshelar,
syzkaller-bugs, yi.y.yang
In-Reply-To: <000000000000798298056e76cbbb@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 6e6fddc78323 bpf: fix panic due to oob in bpf_prog_test_ru..
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=1364db94400000
kernel config: https://syzkaller.appspot.com/x/.config?x=2ca6c7a31d407f86
dashboard link: https://syzkaller.appspot.com/bug?extid=802a5abb8abae86eb6de
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=11572794400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16aff568400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+802a5abb8abae86eb6de@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_UP): veth0: link is not ready
IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
BUG: MAX_LOCK_DEPTH too low!
turning off the locking correctness validator.
depth: 48 max: 48!
48 locks held by syz-executor169/4820:
#0: (____ptrval____) (rcu_read_lock_bh){....}, at:
__dev_queue_xmit+0x328/0x3910 net/core/dev.c:3503
#1: (____ptrval____) (&(&sch->seqlock)->rlock){+...}, at: spin_trylock
include/linux/spinlock.h:320 [inline]
#1: (____ptrval____) (&(&sch->seqlock)->rlock){+...}, at: qdisc_run_begin
include/net/sch_generic.h:124 [inline]
#1: (____ptrval____) (&(&sch->seqlock)->rlock){+...}, at: qdisc_run
include/net/pkt_sched.h:117 [inline]
#1: (____ptrval____) (&(&sch->seqlock)->rlock){+...}, at: __dev_xmit_skb
net/core/dev.c:3229 [inline]
#1: (____ptrval____) (&(&sch->seqlock)->rlock){+...}, at:
__dev_queue_xmit+0x13a3/0x3910 net/core/dev.c:3537
#2: (____ptrval____) (dev->qdisc_running_key ?: &qdisc_running_key){+...},
at: dev_queue_xmit+0x17/0x20 net/core/dev.c:3602
#3: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#3: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#4: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#4: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#5: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#5: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#6: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#6: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#7: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#7: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#8: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#8: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#9: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#9: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#10: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#10: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#11: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#11: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#12: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#12: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#13: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#13: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#14: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#14: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#15: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#15: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#16: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#16: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#17: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#17: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#18: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#18: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#19: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#19: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#20: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#20: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#21: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#21: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#22: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#22: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#23: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#23: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#24: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#24: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#25: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#25: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#26: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#26: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#27: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#27: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#28: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#28: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#29: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#29: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#30: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#30: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#31: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#31: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#32: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#32: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#33: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#33: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#34: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#34: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#35: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#35: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#36: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#36: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#37: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#37: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#38: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#38: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#39: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#39: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#40: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#40: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#41: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#41: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#42: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#42: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#43: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#43: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#44: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#44: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#45: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#45: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#46: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#46: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#47: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#47: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
INFO: lockdep is turned off.
CPU: 0 PID: 4820 Comm: syz-executor169 Not tainted 4.18.0-rc3+ #8
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+0x1c9/0x2b4 lib/dump_stack.c:113
__lock_acquire+0x175d/0x5020 kernel/locking/lockdep.c:3453
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
rcu_lock_acquire include/linux/rcupdate.h:245 [inline]
rcu_read_lock include/linux/rcupdate.h:631 [inline]
skb_mac_gso_segment+0x263/0x740 net/core/dev.c:2789
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
__skb_gso_segment+0x3c3/0x880 net/core/dev.c:2865
skb_gso_segment include/linux/netdevice.h:4099 [inline]
validate_xmit_skb+0x640/0xf30 net/core/dev.c:3104
validate_xmit_skb_list+0xbf/0x120 net/core/dev.c:3154
sch_direct_xmit+0x30e/0x1140 net/sched/sch_generic.c:312
qdisc_restart net/sched/sch_generic.c:390 [inline]
__qdisc_run+0x619/0x19f0 net/sched/sch_generic.c:398
qdisc_run include/net/pkt_sched.h:118 [inline]
__dev_xmit_skb net/core/dev.c:3229 [inline]
__dev_queue_xmit+0x1419/0x3910 net/core/dev.c:3537
dev_queue_xmit+0x17/0x20 net/core/dev.c:3602
packet_snd net/packet/af_packet.c:2919 [inline]
packet_sendmsg+0x428e/0x6130 net/packet/af_packet.c:2944
sock_sendmsg_nosec net/socket.c:641 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:651
___sys_sendmsg+0x7fd/0x930 net/socket.c:2125
__sys_sendmsg+0x11d/0x290 net/socket.c:2163
__do_sys_sendmsg net/socket.c:2172 [inline]
__se_sys_sendmsg net/socket.c:2170 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2170
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x446a99
Code: e8 9c bb 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 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 0b 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f18672ffdb8 EFLAGS: 00000297 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000006dcc24 RCX: 0000000000446a99
RDX: 0000000000000000 RSI: 0000000020000480 RDI: 0000000000000004
RBP: 00000000006dcc20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000
R13: 00007ffcf80e967f R14: 00007f18673009c0 R15: 0000000000000007
==================================================================
------------[ cut here ]------------
BUG: KASAN: stack-out-of-bounds in lookup_object lib/debugobjects.c:157
[inline]
BUG: KASAN: stack-out-of-bounds in debug_object_deactivate+0x425/0x450
lib/debugobjects.c:540
ODEBUG: deactivate not available (active state 0) object type: hrtimer
hint: tick_sched_timer+0x0/0x130 kernel/time/tick-sched.c:66
Read of size 8 at addr ffff8801d770f830 by task syz-executor169/4820
WARNING: CPU: 1 PID: 0 at lib/debugobjects.c:329
debug_print_object+0x16a/0x210 lib/debugobjects.c:326
^ permalink raw reply
* Re: [PATCH mlx5-next v1 2/8] net/mlx5: Add support for flow table destination number
From: Jason Gunthorpe @ 2018-07-12 21:26 UTC (permalink / raw)
To: Or Gerlitz
Cc: Yishai Hadas, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <CAJ3xEMgFknMqJq=BY9SxWpPJDrm1BYBVfQWzyhYk5cdELsaoRQ@mail.gmail.com>
On Fri, Jul 13, 2018 at 12:00:41AM +0300, Or Gerlitz wrote:
> On Wed, Jul 11, 2018 at 2:10 PM, Leon Romanovsky <leon@kernel.org> wrote:
> > From: Yishai Hadas <yishaih@mellanox.com>
> >
> > Add support to set a destination from a flow table number.
> > This functionality will be used in downstream patches from this
> > series by the DEVX stuff.
>
> Reading your cover letter, I still don't understand what is missing
> in the current mlx5 fs core API for your needs. After all, you do
> create flow tables from the IB driver through fs core calls, right?
> so @ the end of the day, you have the FT pointer to provide the
> core, why you need the FT number?
Via the devx API userspace can create flow tables directly without
going to the driver's flow steering core.
Jason
^ permalink raw reply
* Re: [BUG] bonded interfaces drop bpdu (stp) frames
From: Mahesh Bandewar (महेश बंडेवार) @ 2018-07-12 21:26 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Michal Soltys, Chonggang Li, linux-netdev
In-Reply-To: <27709.1531418607@nyx>
On Thu, Jul 12, 2018 at 11:03 AM, Jay Vosburgh
<jay.vosburgh@canonical.com> wrote:
> Michal Soltys <soltys@ziu.info> wrote:
>
>>On 07/12/2018 04:51 PM, Jay Vosburgh wrote:
>>> Mahesh Bandewar (महेश बंडेवार) wrote:
>>>
>>>> On Wed, Jul 11, 2018 at 3:23 PM, Michal Soltys <soltys@ziu.info> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> As weird as that sounds, this is what I observed today after bumping
>>>>> kernel version. I have a setup where 2 bonds are attached to linux
>>>>> bridge and physically are connected to two switches doing MSTP (and
>>>>> linux bridge is just passing them).
>>>>>
>>>>> Initially I suspected some changes related to bridge code - but quick
>>>>> peek at the code showed nothing suspicious - and the part of it that
>>>>> explicitly passes stp frames if stp is not enabled has seen little
>>>>> changes (e.g. per-port group_fwd_mask added recently). Furthermore - if
>>>>> regular non-bonded interfaces are attached everything works fine.
>>>>>
>>>>> Just to be sure I detached the bond (802.3ad mode) and checked it with
>>>>> simple tcpdump (ether proto \\stp) - and indeed no hello packets were
>>>>> there (with them being present just fine on active enslaved interface,
>>>>> or on the bond device in earlier kernels).
>>>>>
>>>>> If time permits I'll bisect tommorow to pinpoint the commit, but from
>>>>> quick todays test - 4.9.x is working fine, while 4.16.16 (tested on
>>>>> debian) and 4.17.3 (tested on archlinux) are failing.
>>>>>
>>>>> Unless this is already a known issue (or you have any suggestions what
>>>>> could be responsible).
>>>>>
>>>> I believe these are link-local-multicast messages and sometime back a
>>>> change went into to not pass those frames to the bonding master. This
>>>> could be the side effect of that.
>>>
>>> Mahesh, I suspect you're thinking of:
>>>
>>> commit b89f04c61efe3b7756434d693b9203cc0cce002e
>>> Author: Chonggang Li <chonggangli@google.com>
>>> Date: Sun Apr 16 12:02:18 2017 -0700
>>>
>>> bonding: deliver link-local packets with skb->dev set to link that packets arrived on
>>>
>>> Michal, are you able to revert this patch and test?
>>>
>>> -J
>>>
>>> ---
>>> -Jay Vosburgh, jay.vosburgh@canonical.com
>>>
>>
>>
>>Just tested - yes, reverting that patch solves the issues.
>
> Chonggang,
>
> Reading the changelog in your commit referenced above, I'm not
> entirely sure what actual problem it is fixing. Could you elaborate?
>
> As the patch appears to cause a regression, it needs to be
> either fixed or reverted.
>
> Mahesh, you signed-off on it as well, perhaps you also have some
> context?
>
I think the original idea behind it was to pass the LLDPDUs to the
stack on the interface that they came on since this is considered to
be link-local traffic and passing to bond-master would loose it's
"linklocal-ness". This is true for LLDP and if you change the skb->dev
of the packet, then you don't know which slave link it came on in
(from LLDP consumer's perspective).
I don't know much about STP but trunking two links and aggregating
this link info through bond-master seems wrong. Just like LLDP, you
are losing info specific to a link and the decision derived from that
info could be wrong.
Having said that, we determine "linklocal-ness" by looking at L2 and
bondmaster shares this with lts slaves. So it does seem fair to pass
those frames to the bonding-master but at the same time link-local
traffic is supposed to be limited to the physical link (LLDP/STP/LACP
etc). Your thoughts?
> -J
>
> ---
> -Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] virtio: support packed ring
From: David Miller @ 2018-07-12 21:44 UTC (permalink / raw)
To: tiwei.bie; +Cc: virtio-dev, mst, netdev, linux-kernel, virtualization, wexu
In-Reply-To: <20180711022711.7090-1-tiwei.bie@intel.com>
From: Tiwei Bie <tiwei.bie@intel.com>
Date: Wed, 11 Jul 2018 10:27:06 +0800
> Hello everyone,
>
> This patch set implements packed ring support in virtio driver.
>
> Some functional tests have been done with Jason's
> packed ring implementation in vhost:
>
> https://lkml.org/lkml/2018/7/3/33
>
> Both of ping and netperf worked as expected.
Michael and Jason, where are we with this series?
^ permalink raw reply
* Re: [PATCH net-next][RESEND] net/tls: Use aead_request_alloc/free for request alloc/free
From: David Miller @ 2018-07-12 21:45 UTC (permalink / raw)
To: vakul.garg; +Cc: netdev, linux-kernel, borisp, aviadye, davejwatson
In-Reply-To: <20180711090220.14697-1-vakul.garg@nxp.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Wed, 11 Jul 2018 14:32:20 +0530
> Instead of kzalloc/free for aead_request allocation and free, use
> functions aead_request_alloc(), aead_request_free(). It ensures that
> any sensitive crypto material held in crypto transforms is securely
> erased from memory.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] tcp: fix sequence numbers for repaired sockets re-using TIME-WAIT sockets
From: David Miller @ 2018-07-12 21:34 UTC (permalink / raw)
To: sbaranoff; +Cc: netdev, avagin, xemul, edumazet, kuznet, yoshfuji
In-Reply-To: <1531257920-573-1-git-send-email-sbaranoff@gmail.com>
From: Stefan Baranoff <sbaranoff@gmail.com>
Date: Tue, 10 Jul 2018 17:25:20 -0400
> This patch fixes a bug where the sequence numbers of a socket created using
> TCP repair functionality are lower than set after connect is called.
> This occurs when the repair socket overlaps with a TIME-WAIT socket and
> triggers the re-use code. The amount lower is equal to the number of times
> that a particular IP/port set is re-used and then put back into TIME-WAIT.
> Re-using the first time the sequence number is 1 lower, closing that socket
> and then re-opening (with repair) a new socket with the same addresses/ports
> puts the sequence number 2 lower than set via setsockopt. The third time is
> 3 lower, etc. I have not tested what the limit of this acrewal is, if any.
>
> The fix is, if a socket is in repair mode, to respect the already set
> sequence number and timestamp when it would have already re-used the
> TIME-WAIT socket.
>
> Signed-off-by: Stefan Baranoff <sbaranoff@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tcp: allow user to create repair socket without window probes
From: David Miller @ 2018-07-12 21:34 UTC (permalink / raw)
To: sbaranoff; +Cc: netdev, avagin, xemul, edumazet, kuznet, yoshfuji
In-Reply-To: <1531258270-1046-1-git-send-email-sbaranoff@gmail.com>
From: Stefan Baranoff <sbaranoff@gmail.com>
Date: Tue, 10 Jul 2018 17:31:10 -0400
> Under rare conditions where repair code may be used it is possible that
> window probes are either unnecessary or undesired. If the user knows that
> window probes are not wanted or needed this change allows them to skip
> sending them when a socket comes out of repair.
>
> Signed-off-by: Stefan Baranoff <sbaranoff@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 00/14] ARM BPF jit compiler improvements
From: Russell King - ARM Linux @ 2018-07-12 21:35 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, linux-arm-kernel
In-Reply-To: <fbfa3684-b5a0-670d-c8f7-8c14829565cb@iogearbox.net>
On Thu, Jul 12, 2018 at 11:12:45PM +0200, Daniel Borkmann wrote:
> On 07/12/2018 11:02 PM, Russell King - ARM Linux wrote:
> > On Thu, Jul 12, 2018 at 09:02:41PM +0200, Daniel Borkmann wrote:
> >> Applied to bpf-next, thanks a lot Russell!
> >
> > Thanks, I've just sent four more patches, which is the sum total of
> > what I'm intending to send for BPF improvements for the next merge
> > window.
>
> Great, thanks a lot for the batch of improvements, Russell!
>
> Did you manage to get the BPF kselftest suite working on arm32 under
> tools/testing/selftests/bpf/? In particular the test_verfier with
> bpf_jit_enabled set to 1 and test_kmod.sh has a bigger number of
> runtime tests that would stress it.
I have a big issue with almost all of the tools/ subdirectory, and
that is that it isn't "portable".
It seems that cross-build environments just weren't considered when
the tools subdirectory was created - it appears to require the entire
kernel tree and build tree to be accessible on the target in order
to build almost everything there. (I also exclusively do split-object
builds, I never do an in-source-tree build.)
At least perf has the ability to ask Kbuild to package it up as a
tar.* file. That can be easily transported to the target as a
self-contained buildable tree, and then be able to built from that.
My cross-build environment for the kernel is just for building
kernels, it does not have the facilities to build for userspace - I
have a wide range of userspaces across targets, with a multitude of
different glibc versions, and even when they're compatible versions,
they're built differently.
As far as I can see, basically, most tools/ stuff requires too much
effort to work around this to be of any use to me. Even if I did
unpick it from the kernel source tree by hand, that would be wasted
effort, because I'd need to repeat that same process whenever
anything there gets updated.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* Re: [PATCH] [RESEND, net-next, v2] tcp: use monotonic timestamps for PAWS
From: David Miller @ 2018-07-12 21:50 UTC (permalink / raw)
To: arnd
Cc: edumazet, kuznet, yoshfuji, harsh, herbert, atul.gupta, gustavo,
werner, linux-crypto, linux-kernel, netdev
In-Reply-To: <20180711101757.3929777-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 11 Jul 2018 12:16:12 +0200
> Using get_seconds() for timestamps is deprecated since it can lead
> to overflows on 32-bit systems. While the interface generally doesn't
> overflow until year 2106, the specific implementation of the TCP PAWS
> algorithm breaks in 2038 when the intermediate signed 32-bit timestamps
> overflow.
>
> A related problem is that the local timestamps in CLOCK_REALTIME form
> lead to unexpected behavior when settimeofday is called to set the system
> clock backwards or forwards by more than 24 days.
>
> While the first problem could be solved by using an overflow-safe method
> of comparing the timestamps, a nicer solution is to use a monotonic
> clocksource with ktime_get_seconds() that simply doesn't overflow (at
> least not until 136 years after boot) and that doesn't change during
> settimeofday().
>
> To make 32-bit and 64-bit architectures behave the same way here, and
> also save a few bytes in the tcp_options_received structure, I'm changing
> the type to a 32-bit integer, which is now safe on all architectures.
>
> Finally, the ts_recent_stamp field also (confusingly) gets used to store
> a jiffies value in tcp_synq_overflow()/tcp_synq_no_recent_overflow().
> This is currently safe, but changing the type to 32-bit requires
> some small changes there to keep it working.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v2: use time_before32()/time_after32() everywhere as suggested
> Eric Dumazet in https://lore.kernel.org/lkml/67ebb94d-c73f-6c9f-493b-00c86f595120@gmail.com/
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] [RESEND] liquidio: use ktime_get_real_ts64() instead of getnstimeofday64()
From: David Miller @ 2018-07-12 21:56 UTC (permalink / raw)
To: arnd
Cc: derek.chickles, satananda.burla, felix.manlunas, raghu.vatsavayi,
intiyaz.basha, ricardo.farrington, veerasenareddy.burru,
vijaya.guvva, weilin.chang, netdev, linux-kernel
In-Reply-To: <20180711123003.453442-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 11 Jul 2018 14:29:52 +0200
> The two do the same thing, but we want to have a consistent
> naming in the kernel.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 2/2] [RESEND] nfp: avoid using getnstimeofday64()
From: David Miller @ 2018-07-12 21:56 UTC (permalink / raw)
To: arnd
Cc: jakub.kicinski, john.hurley, simon.horman, pieter.jansenvanvuuren,
jiri, oss-drivers, netdev, linux-kernel
In-Reply-To: <20180711123003.453442-2-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 11 Jul 2018 14:29:53 +0200
> getnstimeofday64 is deprecated in favor of the ktime_get() family of
> functions. The direct replacement would be ktime_get_real_ts64(),
> but I'm picking the basic ktime_get() instead:
>
> - using a ktime_t simplifies the code compared to timespec64
> - using monotonic time instead of real time avoids issues caused
> by a concurrent settimeofday() or during a leap second adjustment.
>
> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net] net: systemport: Fix CRC forwarding check for SYSTEMPORT Lite
From: David Miller @ 2018-07-12 21:47 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, linux-kernel
In-Reply-To: <20180711094758.1670-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 11 Jul 2018 02:47:58 -0700
> SYSTEMPORT Lite reversed the logic compared to SYSTEMPORT, the
> GIB_FCS_STRIP bit is set when the Ethernet FCS is stripped, and that bit
> is not set by default. Fix the logic such that we properly check whether
> that bit is set or not and we don't forward an extra 4 bytes to the
> network stack.
>
> Fixes: 44a4524c54af ("net: systemport: Add support for SYSTEMPORT Lite")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* [PATCH net] net/ipv6: Do not allow device only routes via the multipath API
From: dsahern @ 2018-07-12 21:48 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, David Ahern
From: David Ahern <dsahern@gmail.com>
Eric reported that reverting the patch that fixed and simplified IPv6
multipath routes means reverting back to invalid userspace notifications.
eg.,
$ ip -6 route add 2001:db8:1::/64 nexthop dev eth0 nexthop dev eth1
only generates a single notification:
2001:db8:1::/64 dev eth0 metric 1024 pref medium
While working on a fix for this problem I found another case that is just
broken completely - a multipath route with a gateway followed by device
followed by gateway:
$ ip -6 ro add 2001:db8:103::/64
nexthop via 2001:db8:1::64
nexthop dev dummy2
nexthop via 2001:db8:3::64
In this case the device only route is dropped completely - no notification
to userpsace but no addition to the FIB either:
$ ip -6 ro ls
2001:db8:1::/64 dev dummy1 proto kernel metric 256 pref medium
2001:db8:2::/64 dev dummy2 proto kernel metric 256 pref medium
2001:db8:3::/64 dev dummy3 proto kernel metric 256 pref medium
2001:db8:103::/64 metric 1024
nexthop via 2001:db8:1::64 dev dummy1 weight 1
nexthop via 2001:db8:3::64 dev dummy3 weight 1 pref medium
fe80::/64 dev dummy1 proto kernel metric 256 pref medium
fe80::/64 dev dummy2 proto kernel metric 256 pref medium
fe80::/64 dev dummy3 proto kernel metric 256 pref medium
Really, IPv6 multipath is just FUBAR'ed beyond repair when it comes to
device only routes, so do not allow it all.
This change will break any scripts relying on the mpath api for insert,
but I don't see any other way to handle the permutations. Besides, since
the routes are added to the FIB as standalone (non-multipath) routes the
kernel is not doing what the user requested, so it might as well tell the
user that.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/ipv6/route.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 63f99411f0de..1f1f0f318d74 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -4388,6 +4388,13 @@ static int ip6_route_multipath_add(struct fib6_config *cfg,
rt = NULL;
goto cleanup;
}
+ if (!rt6_qualify_for_ecmp(rt)) {
+ err = EINVAL;
+ NL_SET_ERR_MSG(extack,
+ "Device only routes can not be added for IPv6 using the multipath API.");
+ fib6_info_release(rt);
+ goto cleanup;
+ }
rt->fib6_nh.nh_weight = rtnh->rtnh_hops + 1;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH mlx5-next v1 2/8] net/mlx5: Add support for flow table destination number
From: Or Gerlitz @ 2018-07-12 21:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Yishai Hadas, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180712212618.GS30390@mellanox.com>
On Fri, Jul 13, 2018 at 12:26 AM, Jason Gunthorpe <jgg@mellanox.com> wrote:
> On Fri, Jul 13, 2018 at 12:00:41AM +0300, Or Gerlitz wrote:
>> On Wed, Jul 11, 2018 at 2:10 PM, Leon Romanovsky <leon@kernel.org> wrote:
>> > From: Yishai Hadas <yishaih@mellanox.com>
>> >
>> > Add support to set a destination from a flow table number.
>> > This functionality will be used in downstream patches from this
>> > series by the DEVX stuff.
>>
>> Reading your cover letter, I still don't understand what is missing
>> in the current mlx5 fs core API for your needs. After all, you do
>> create flow tables from the IB driver through fs core calls, right?
>> so @ the end of the day, you have the FT pointer to provide the
>> core, why you need the FT number?
>
> Via the devx API userspace can create flow tables directly without
> going to the driver's flow steering core.
so why you change the core?
^ permalink raw reply
* Re: [PATCH net 0/2] sfc: filter locking fixes
From: David Miller @ 2018-07-12 21:52 UTC (permalink / raw)
To: bkenward; +Cc: netdev, linux-net-drivers
In-Reply-To: <ffa1a8d2-7906-29f9-6089-f968aa376681@solarflare.com>
From: Bert Kenward <bkenward@solarflare.com>
Date: Wed, 11 Jul 2018 11:39:39 +0100
> Two fixes for sfc ef10 filter table locking. Initially spotted
> by lockdep, but one issue has also been seen in normal use.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] net/sched: act_skbedit: lockless data path
From: David Miller @ 2018-07-12 21:54 UTC (permalink / raw)
To: dcaratti; +Cc: xiyou.wangcong, netdev
In-Reply-To: <cover.1531315251.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Wed, 11 Jul 2018 16:04:48 +0200
> the data path of act_skbedit can be faster if we avoid using spinlocks:
> - patch 1 converts act_skbedit statistics to use per-cpu counters
> - patch 2 lets act_skbedit use RCU to read/update its configuration
>
> test procedure (using pktgen from https://github.com/netoptimizer):
>
> # ip link add name eth1 type dummy
> # ip link set dev eth1 up
> # tc qdisc add dev eth1 clsact
> # tc filter add dev eth1 egress matchall action skbedit priority c1a0:c1a0
> # for c in 1 2 4 ; do
> > ./pktgen_bench_xmit_mode_queue_xmit.sh -v -s 64 -t $c -n 5000000 -i eth1
> > done
>
> test results (avg. pps/thread)
>
> $c | before patch | after patch | improvement
> ----+--------------+--------------+------------
> 1 | 3917464 ± 3% | 4000458 ± 3% | irrelevant
> 2 | 3455367 ± 4% | 3953076 ± 1% | +14%
> 4 | 2496594 ± 2% | 3801123 ± 3% | +52%
>
> v2: rebased on latest net-next
Series applied, thank you.
^ permalink raw reply
* Re: [BUG] bonded interfaces drop bpdu (stp) frames
From: Jay Vosburgh @ 2018-07-12 22:03 UTC (permalink / raw)
To: =?UTF-8?B?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS14KS+4KSwKQ==?=
Cc: Michal Soltys, Chonggang Li, linux-netdev
In-Reply-To: <CAF2d9jjXmiVZwDu-q+M5bmdrgyMr0U_tiUzxoCUiWwZT4NS5Cw@mail.gmail.com>
Mahesh Bandewar (महेश बंडेवार) wrote:
>On Thu, Jul 12, 2018 at 11:03 AM, Jay Vosburgh
><jay.vosburgh@canonical.com> wrote:
>> Michal Soltys <soltys@ziu.info> wrote:
>>
>>>On 07/12/2018 04:51 PM, Jay Vosburgh wrote:
>>>> Mahesh Bandewar (महेश बंडेवार) wrote:
>>>>
>>>>> On Wed, Jul 11, 2018 at 3:23 PM, Michal Soltys <soltys@ziu.info> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> As weird as that sounds, this is what I observed today after bumping
>>>>>> kernel version. I have a setup where 2 bonds are attached to linux
>>>>>> bridge and physically are connected to two switches doing MSTP (and
>>>>>> linux bridge is just passing them).
>>>>>>
>>>>>> Initially I suspected some changes related to bridge code - but quick
>>>>>> peek at the code showed nothing suspicious - and the part of it that
>>>>>> explicitly passes stp frames if stp is not enabled has seen little
>>>>>> changes (e.g. per-port group_fwd_mask added recently). Furthermore - if
>>>>>> regular non-bonded interfaces are attached everything works fine.
>>>>>>
>>>>>> Just to be sure I detached the bond (802.3ad mode) and checked it with
>>>>>> simple tcpdump (ether proto \\stp) - and indeed no hello packets were
>>>>>> there (with them being present just fine on active enslaved interface,
>>>>>> or on the bond device in earlier kernels).
>>>>>>
>>>>>> If time permits I'll bisect tommorow to pinpoint the commit, but from
>>>>>> quick todays test - 4.9.x is working fine, while 4.16.16 (tested on
>>>>>> debian) and 4.17.3 (tested on archlinux) are failing.
>>>>>>
>>>>>> Unless this is already a known issue (or you have any suggestions what
>>>>>> could be responsible).
>>>>>>
>>>>> I believe these are link-local-multicast messages and sometime back a
>>>>> change went into to not pass those frames to the bonding master. This
>>>>> could be the side effect of that.
>>>>
>>>> Mahesh, I suspect you're thinking of:
>>>>
>>>> commit b89f04c61efe3b7756434d693b9203cc0cce002e
>>>> Author: Chonggang Li <chonggangli@google.com>
>>>> Date: Sun Apr 16 12:02:18 2017 -0700
>>>>
>>>> bonding: deliver link-local packets with skb->dev set to link that packets arrived on
>>>>
>>>> Michal, are you able to revert this patch and test?
>>>>
>>>> -J
>>>>
>>>> ---
>>>> -Jay Vosburgh, jay.vosburgh@canonical.com
>>>>
>>>
>>>
>>>Just tested - yes, reverting that patch solves the issues.
>>
>> Chonggang,
>>
>> Reading the changelog in your commit referenced above, I'm not
>> entirely sure what actual problem it is fixing. Could you elaborate?
>>
>> As the patch appears to cause a regression, it needs to be
>> either fixed or reverted.
>>
>> Mahesh, you signed-off on it as well, perhaps you also have some
>> context?
>>
>
>I think the original idea behind it was to pass the LLDPDUs to the
>stack on the interface that they came on since this is considered to
>be link-local traffic and passing to bond-master would loose it's
>"linklocal-ness". This is true for LLDP and if you change the skb->dev
>of the packet, then you don't know which slave link it came on in
>(from LLDP consumer's perspective).
>
>I don't know much about STP but trunking two links and aggregating
>this link info through bond-master seems wrong. Just like LLDP, you
>are losing info specific to a link and the decision derived from that
>info could be wrong.
>
>Having said that, we determine "linklocal-ness" by looking at L2 and
>bondmaster shares this with lts slaves. So it does seem fair to pass
>those frames to the bonding-master but at the same time link-local
>traffic is supposed to be limited to the physical link (LLDP/STP/LACP
>etc). Your thoughts?
I agree the whole thing sounds kind of weird, but I'm curious as
to what Michal's actual use case is; he presumably has some practical
use for this, since he noticed that the behavior changed.
Michal, you mentioned MSTP and using 802.3ad (LACP) mode; how
does that combination work rationally given that the bond might send and
receive traffic across multiple slaves? Or does the switch side bundle
the ports together into a single logical interface for MSTP purposes?
On the TX side, I think the bond will likely balance all STP frames to
just one slave.
As for a resolution, presuming that Michal has some reasonable
use case, I'm thinking along the lines of reverting the new (leave frame
attached to slave) behavior for the general case and adding a special
case for LLDP and friends to get the new behavior. I'd like to avoid
adding any new options to bonding.
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH iproute2-next v2] net:sched: add action inheritdsfield to skbedit
From: Stephen Hemminger @ 2018-07-12 22:05 UTC (permalink / raw)
To: Qiaobin Fu
Cc: dsahern, davem, netdev, jhs, michel, marcelo.leitner,
xiyou.wangcong, dcaratti
In-Reply-To: <20180712160926.163317-1-qiaobinf@bu.edu>
On Thu, 12 Jul 2018 12:09:26 -0400
Qiaobin Fu <qiaobinf@bu.edu> wrote:
> + if (*flags & SKBEDIT_F_INHERITDSFIELD)
> + print_string(PRINT_ANY, "inheritdsfield", " %s",
> + "inheritdsfield");
Flags should be represented in JSON output as a null value (or boolean).
print_null(PRINT_ANY, "inheritdsfield", " %s", "inheritdsfield");
This will generate:
"inheritdsfield" : null,
Instead of:
"inheritdsfield" : "inheritdsfield",
^ permalink raw reply
* Re: [PATCH mlx5-next v1 2/8] net/mlx5: Add support for flow table destination number
From: Jason Gunthorpe @ 2018-07-12 22:05 UTC (permalink / raw)
To: Or Gerlitz
Cc: Yishai Hadas, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <CAJ3xEMg-cfRwZTwK2Eu2cdH1YuSF5rJy88YWYrbyWywKun5hPg@mail.gmail.com>
On Fri, Jul 13, 2018 at 12:51:10AM +0300, Or Gerlitz wrote:
> On Fri, Jul 13, 2018 at 12:26 AM, Jason Gunthorpe <jgg@mellanox.com> wrote:
> > On Fri, Jul 13, 2018 at 12:00:41AM +0300, Or Gerlitz wrote:
> >> On Wed, Jul 11, 2018 at 2:10 PM, Leon Romanovsky <leon@kernel.org> wrote:
> >> > From: Yishai Hadas <yishaih@mellanox.com>
> >> >
> >> > Add support to set a destination from a flow table number.
> >> > This functionality will be used in downstream patches from this
> >> > series by the DEVX stuff.
> >>
> >> Reading your cover letter, I still don't understand what is missing
> >> in the current mlx5 fs core API for your needs. After all, you do
> >> create flow tables from the IB driver through fs core calls, right?
> >> so @ the end of the day, you have the FT pointer to provide the
> >> core, why you need the FT number?
> >
> > Via the devx API userspace can create flow tables directly without
> > going to the driver's flow steering core.
>
> so why you change the core?
User space flow tables don't get any traffic until they are linked
into the main steering. The only ID the kernel gets for them when
adding this link is the actual PRM handle, not a pointer - hence the
change.
Jason
^ 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