* Re: KASAN: use-after-free Write in nr_insert_socket
From: Dmitry Vyukov @ 2019-07-23 16:24 UTC (permalink / raw)
To: syzbot, Ralf Baechle, David Miller, linux-hams, netdev
Cc: LKML, syzkaller-bugs
In-Reply-To: <0000000000006241fe058e5b9490@google.com>
On Tue, Jul 23, 2019 at 6:21 PM syzbot
<syzbot+5e54e8e637bc970bbd2b@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: c6dd78fc Merge branch 'x86-urgent-for-linus' of git://git...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=178a5c10600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=3c8985c08e1f9727
> dashboard link: https://syzkaller.appspot.com/bug?extid=5e54e8e637bc970bbd2b
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+5e54e8e637bc970bbd2b@syzkaller.appspotmail.com
+net/netrom/af_netrom.c maintainers
> ==================================================================
> BUG: KASAN: use-after-free in atomic_try_cmpxchg
> /./include/asm-generic/atomic-instrumented.h:693 [inline]
> BUG: KASAN: use-after-free in refcount_inc_not_zero_checked+0xef/0x200
> /lib/refcount.c:134
> Write of size 4 at addr ffff88805b0a2d00 by task syz-executor.1/29302
>
> CPU: 1 PID: 29302 Comm: syz-executor.1 Not tainted 5.2.0+ #64
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack /lib/dump_stack.c:77 [inline]
> dump_stack+0x16f/0x1f0 /lib/dump_stack.c:113
> print_address_description.cold+0xd4/0x306 /mm/kasan/report.c:351
> __kasan_report.cold+0x1b/0x36 /mm/kasan/report.c:482
> kasan_report+0x12/0x17 /mm/kasan/common.c:612
> check_memory_region_inline /mm/kasan/generic.c:185 [inline]
> check_memory_region+0x134/0x1a0 /mm/kasan/generic.c:192
> __kasan_check_write+0x14/0x20 /mm/kasan/common.c:98
> atomic_try_cmpxchg /./include/asm-generic/atomic-instrumented.h:693
> [inline]
> refcount_inc_not_zero_checked+0xef/0x200 /lib/refcount.c:134
> refcount_inc_checked+0x17/0x70 /lib/refcount.c:156
> sock_hold /./include/net/sock.h:649 [inline]
> sk_add_node /./include/net/sock.h:701 [inline]
> nr_insert_socket+0x2d/0xe0 /net/netrom/af_netrom.c:137
> nr_rx_frame+0x1605/0x1e73 /net/netrom/af_netrom.c:1023
> nr_loopback_timer+0x7b/0x170 /net/netrom/nr_loopback.c:59
> call_timer_fn+0x1ac/0x700 /kernel/time/timer.c:1322
> expire_timers /kernel/time/timer.c:1366 [inline]
> __run_timers /kernel/time/timer.c:1685 [inline]
> __run_timers /kernel/time/timer.c:1653 [inline]
> run_timer_softirq+0x66c/0x16a0 /kernel/time/timer.c:1698
> __do_softirq+0x30d/0x970 /kernel/softirq.c:292
> invoke_softirq /kernel/softirq.c:373 [inline]
> irq_exit+0x1d0/0x200 /kernel/softirq.c:413
> exiting_irq /./arch/x86/include/asm/apic.h:537 [inline]
> smp_apic_timer_interrupt+0x14e/0x550 /arch/x86/kernel/apic/apic.c:1095
> apic_timer_interrupt+0xf/0x20 /arch/x86/entry/entry_64.S:828
> </IRQ>
> RIP: 0010:__preempt_count_sub /./arch/x86/include/asm/preempt.h:84 [inline]
> RIP: 0010:__raw_spin_unlock_irq /./include/linux/spinlock_api_smp.h:169
> [inline]
> RIP: 0010:_raw_spin_unlock_irq+0x54/0x70 /kernel/locking/spinlock.c:199
> Code: c0 a0 e3 d2 88 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00
> 75 1e 48 83 3d d5 65 a0 01 00 74 12 fb 66 0f 1f 44 00 00 <65> ff 0d ad 7f
> cf 78 41 5c 5d c3 0f 0b 48 c7 c7 a0 e3 d2 88 e8 d3
> RSP: 0018:ffff88808fc87370 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
> RAX: 1ffffffff11a5c74 RBX: ffff888092ace300 RCX: 0000000000000006
> RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff888092aceb4c
> RBP: ffff88808fc87378 R08: 1ffffffff14a6d50 R09: fffffbfff14a6d51
> R10: fffffbfff14a6d50 R11: ffffffff8a536a87 R12: ffff8880ae935380
> R13: ffff888053dde280 R14: 0000000000000000 R15: 0000000000000001
> finish_lock_switch /kernel/sched/core.c:3004 [inline]
> finish_task_switch+0x11d/0x690 /kernel/sched/core.c:3104
> context_switch /kernel/sched/core.c:3257 [inline]
> __schedule+0x77a/0x1530 /kernel/sched/core.c:3880
> preempt_schedule_common+0x35/0x70 /kernel/sched/core.c:4025
> _cond_resched+0x1d/0x30 /kernel/sched/core.c:5423
> generic_perform_write+0x332/0x540 /mm/filemap.c:3344
> __generic_file_write_iter+0x25e/0x630 /mm/filemap.c:3456
> ext4_file_write_iter+0x373/0x1430 /fs/ext4/file.c:270
> call_write_iter /./include/linux/fs.h:1870 [inline]
> do_iter_readv_writev+0x5f8/0x8f0 /fs/read_write.c:693
> do_iter_write /fs/read_write.c:970 [inline]
> do_iter_write+0x184/0x610 /fs/read_write.c:951
> vfs_iter_write+0x77/0xb0 /fs/read_write.c:983
> iter_file_splice_write+0x66d/0xbe0 /fs/splice.c:746
> do_splice_from /fs/splice.c:848 [inline]
> direct_splice_actor+0x123/0x190 /fs/splice.c:1020
> splice_direct_to_actor+0x366/0x970 /fs/splice.c:975
> do_splice_direct+0x1da/0x2a0 /fs/splice.c:1063
> do_sendfile+0x597/0xd00 /fs/read_write.c:1464
> __do_sys_sendfile64 /fs/read_write.c:1519 [inline]
> __se_sys_sendfile64 /fs/read_write.c:1511 [inline]
> __x64_sys_sendfile64+0x15a/0x220 /fs/read_write.c:1511
> do_syscall_64+0xfd/0x6a0 /arch/x86/entry/common.c:296
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x459829
> Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fe4c4360c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 0000000000459829
> RDX: 0000000020000080 RSI: 0000000000000003 RDI: 0000000000000003
> RBP: 000000000075bfc8 R08: 0000000000000000 R09: 0000000000000000
> R10: 000000000000a198 R11: 0000000000000246 R12: 00007fe4c43616d4
> R13: 00000000004c6e87 R14: 00000000004dc238 R15: 00000000ffffffff
>
> Allocated by task 29302:
> save_stack+0x23/0x90 /mm/kasan/common.c:69
> set_track /mm/kasan/common.c:77 [inline]
> __kasan_kmalloc /mm/kasan/common.c:487 [inline]
> __kasan_kmalloc.constprop.0+0xcf/0xe0 /mm/kasan/common.c:460
> kasan_kmalloc+0x9/0x10 /mm/kasan/common.c:501
> __do_kmalloc /mm/slab.c:3655 [inline]
> __kmalloc+0x163/0x760 /mm/slab.c:3664
> kmalloc /./include/linux/slab.h:557 [inline]
> sk_prot_alloc+0x23a/0x310 /net/core/sock.c:1603
> sk_alloc+0x39/0xf60 /net/core/sock.c:1657
> nr_make_new /net/netrom/af_netrom.c:476 [inline]
> nr_rx_frame+0x733/0x1e73 /net/netrom/af_netrom.c:959
> nr_loopback_timer+0x7b/0x170 /net/netrom/nr_loopback.c:59
> call_timer_fn+0x1ac/0x700 /kernel/time/timer.c:1322
> expire_timers /kernel/time/timer.c:1366 [inline]
> __run_timers /kernel/time/timer.c:1685 [inline]
> __run_timers /kernel/time/timer.c:1653 [inline]
> run_timer_softirq+0x66c/0x16a0 /kernel/time/timer.c:1698
> __do_softirq+0x30d/0x970 /kernel/softirq.c:292
>
> Freed by task 29300:
> save_stack+0x23/0x90 /mm/kasan/common.c:69
> set_track /mm/kasan/common.c:77 [inline]
> __kasan_slab_free+0x102/0x150 /mm/kasan/common.c:449
> kasan_slab_free+0xe/0x10 /mm/kasan/common.c:457
> __cache_free /mm/slab.c:3425 [inline]
> kfree+0x10a/0x2a0 /mm/slab.c:3756
> sk_prot_free /net/core/sock.c:1640 [inline]
> __sk_destruct+0x4f7/0x6e0 /net/core/sock.c:1726
> sk_destruct+0x86/0xa0 /net/core/sock.c:1734
> __sk_free+0xfb/0x360 /net/core/sock.c:1745
> sk_free+0x42/0x50 /net/core/sock.c:1756
> sock_put /./include/net/sock.h:1725 [inline]
> sock_efree+0x61/0x80 /net/core/sock.c:2042
> skb_release_head_state+0xeb/0x250 /net/core/skbuff.c:652
> skb_release_all+0x16/0x60 /net/core/skbuff.c:663
> __kfree_skb /net/core/skbuff.c:679 [inline]
> kfree_skb /net/core/skbuff.c:697 [inline]
> kfree_skb+0x101/0x380 /net/core/skbuff.c:691
> nr_accept+0x56e/0x700 /net/netrom/af_netrom.c:819
> __sys_accept4+0x34e/0x6a0 /net/socket.c:1754
> __do_sys_accept4 /net/socket.c:1789 [inline]
> __se_sys_accept4 /net/socket.c:1786 [inline]
> __x64_sys_accept4+0x97/0xf0 /net/socket.c:1786
> do_syscall_64+0xfd/0x6a0 /arch/x86/entry/common.c:296
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff88805b0a2c80
> which belongs to the cache kmalloc-2k of size 2048
> The buggy address is located 128 bytes inside of
> 2048-byte region [ffff88805b0a2c80, ffff88805b0a3480)
> The buggy address belongs to the page:
> page:ffffea00016c2880 refcount:1 mapcount:0 mapping:ffff8880aa400e00
> index:0x0 compound_mapcount: 0
> flags: 0x1fffc0000010200(slab|head)
> raw: 01fffc0000010200 ffffea000180bc08 ffffea00025aef08 ffff8880aa400e00
> raw: 0000000000000000 ffff88805b0a2400 0000000100000003 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff88805b0a2c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88805b0a2c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff88805b0a2d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff88805b0a2d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff88805b0a2e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
> ------------[ cut here ]------------
> ODEBUG: activate not available (active state 0) object type: timer_list
> hint: nr_heartbeat_expiry+0x0/0x410 /net/netrom/nr_timer.c:52
> WARNING: CPU: 1 PID: 29302 at lib/debugobjects.c:481
> debug_print_object+0x168/0x250 /lib/debugobjects.c:481
> Modules linked in:
> CPU: 1 PID: 29302 Comm: syz-executor.1 Tainted: G B 5.2.0+
> #64
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:debug_print_object+0x168/0x250 /lib/debugobjects.c:481
> Code: dd 80 02 c6 87 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 b5 00 00 00 48
> 8b 14 dd 80 02 c6 87 48 c7 c7 80 f7 c5 87 e8 60 0d 09 fe <0f> 0b 83 05 e3
> 68 6a 06 01 48 83 c4 20 5b 41 5c 41 5d 41 5e 5d c3
> RSP: 0018:ffff8880ae9099d0 EFLAGS: 00010082
> RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000000000
> RDX: 0000000000000100 RSI: ffffffff815b9de2 RDI: ffffed1015d2132c
> RBP: ffff8880ae909a10 R08: ffff888092ace300 R09: fffffbfff13494e8
> R10: fffffbfff13494e7 R11: ffffffff89a4a73f R12: 0000000000000001
> R13: ffffffff88db3f40 R14: ffffffff8160d430 R15: 1ffff11015d21348
> FS: 00007fe4c4361700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000001b2e620000 CR3: 000000007bf8a000 CR4: 00000000001406e0
> Call Trace:
> <IRQ>
> debug_object_activate+0x2e5/0x470 /lib/debugobjects.c:680
> debug_timer_activate /kernel/time/timer.c:710 [inline]
> __mod_timer /kernel/time/timer.c:1035 [inline]
> mod_timer+0x415/0xb90 /kernel/time/timer.c:1096
> sk_reset_timer+0x24/0x60 /net/core/sock.c:2821
> nr_start_heartbeat+0x47/0x60 /net/netrom/nr_timer.c:79
> nr_rx_frame+0x160d/0x1e73 /net/netrom/af_netrom.c:1025
> nr_loopback_timer+0x7b/0x170 /net/netrom/nr_loopback.c:59
> call_timer_fn+0x1ac/0x700 /kernel/time/timer.c:1322
> expire_timers /kernel/time/timer.c:1366 [inline]
> __run_timers /kernel/time/timer.c:1685 [inline]
> __run_timers /kernel/time/timer.c:1653 [inline]
> run_timer_softirq+0x66c/0x16a0 /kernel/time/timer.c:1698
> __do_softirq+0x30d/0x970 /kernel/softirq.c:292
> invoke_softirq /kernel/softirq.c:373 [inline]
> irq_exit+0x1d0/0x200 /kernel/softirq.c:413
> exiting_irq /./arch/x86/include/asm/apic.h:537 [inline]
> smp_apic_timer_interrupt+0x14e/0x550 /arch/x86/kernel/apic/apic.c:1095
> apic_timer_interrupt+0xf/0x20 /arch/x86/entry/entry_64.S:828
> </IRQ>
> RIP: 0010:__preempt_count_sub /./arch/x86/include/asm/preempt.h:84 [inline]
> RIP: 0010:__raw_spin_unlock_irq /./include/linux/spinlock_api_smp.h:169
> [inline]
> RIP: 0010:_raw_spin_unlock_irq+0x54/0x70 /kernel/locking/spinlock.c:199
> Code: c0 a0 e3 d2 88 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00
> 75 1e 48 83 3d d5 65 a0 01 00 74 12 fb 66 0f 1f 44 00 00 <65> ff 0d ad 7f
> cf 78 41 5c 5d c3 0f 0b 48 c7 c7 a0 e3 d2 88 e8 d3
> RSP: 0018:ffff88808fc87370 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
> RAX: 1ffffffff11a5c74 RBX: ffff888092ace300 RCX: 0000000000000006
> RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff888092aceb4c
> RBP: ffff88808fc87378 R08: 1ffffffff14a6d50 R09: fffffbfff14a6d51
> R10: fffffbfff14a6d50 R11: ffffffff8a536a87 R12: ffff8880ae935380
> R13: ffff888053dde280 R14: 0000000000000000 R15: 0000000000000001
> finish_lock_switch /kernel/sched/core.c:3004 [inline]
> finish_task_switch+0x11d/0x690 /kernel/sched/core.c:3104
> context_switch /kernel/sched/core.c:3257 [inline]
> __schedule+0x77a/0x1530 /kernel/sched/core.c:3880
> preempt_schedule_common+0x35/0x70 /kernel/sched/core.c:4025
> _cond_resched+0x1d/0x30 /kernel/sched/core.c:5423
> generic_perform_write+0x332/0x540 /mm/filemap.c:3344
> __generic_file_write_iter+0x25e/0x630 /mm/filemap.c:3456
> ext4_file_write_iter+0x373/0x1430 /fs/ext4/file.c:270
> call_write_iter /./include/linux/fs.h:1870 [inline]
> do_iter_readv_writev+0x5f8/0x8f0 /fs/read_write.c:693
> do_iter_write /fs/read_write.c:970 [inline]
> do_iter_write+0x184/0x610 /fs/read_write.c:951
> vfs_iter_write+0x77/0xb0 /fs/read_write.c:983
> iter_file_splice_write+0x66d/0xbe0 /fs/splice.c:746
> do_splice_from /fs/splice.c:848 [inline]
> direct_splice_actor+0x123/0x190 /fs/splice.c:1020
> splice_direct_to_actor+0x366/0x970 /fs/splice.c:975
> do_splice_direct+0x1da/0x2a0 /fs/splice.c:1063
> do_sendfile+0x597/0xd00 /fs/read_write.c:1464
> __do_sys_sendfile64 /fs/read_write.c:1519 [inline]
> __se_sys_sendfile64 /fs/read_write.c:1511 [inline]
> __x64_sys_sendfile64+0x15a/0x220 /fs/read_write.c:1511
> do_syscall_64+0xfd/0x6a0 /arch/x86/entry/common.c:296
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x459829
> Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fe4c4360c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 0000000000459829
> RDX: 0000000020000080 RSI: 0000000000000003 RDI: 0000000000000003
> RBP: 000000000075bfc8 R08: 0000000000000000 R09: 0000000000000000
> R10: 000000000000a198 R11: 0000000000000246 R12: 00007fe4c43616d4
> R13: 00000000004c6e87 R14: 00000000004dc238 R15: 00000000ffffffff
> irq event stamp: 9211
> hardirqs last enabled at (9210): [<ffffffff8100651a>]
> trace_hardirqs_on_thunk+0x1a/0x20 /arch/x86/entry/thunk_64.S:41
> hardirqs last disabled at (9211): [<ffffffff8732831f>]
> __raw_spin_lock_irqsave /./include/linux/spinlock_api_smp.h:108 [inline]
> hardirqs last disabled at (9211): [<ffffffff8732831f>]
> _raw_spin_lock_irqsave+0x6f/0xd0 /kernel/locking/spinlock.c:159
> softirqs last enabled at (8598): [<ffffffff8760069a>]
> __do_softirq+0x69a/0x970 /kernel/softirq.c:319
> softirqs last disabled at (8879): [<ffffffff814526b0>] invoke_softirq
> /kernel/softirq.c:373 [inline]
> softirqs last disabled at (8879): [<ffffffff814526b0>] irq_exit+0x1d0/0x200
> /kernel/softirq.c:413
> ---[ end trace 1f19b790eed0288b ]---
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/0000000000006241fe058e5b9490%40google.com.
^ permalink raw reply
* [PATCH v1] hv_sock: Use consistent types for UUIDs
From: Andy Shevchenko @ 2019-07-23 16:39 UTC (permalink / raw)
To: Haiyang Zhang, K. Y. Srinivasan, Stephen Hemminger, Sasha Levin,
linux-hyperv, David S. Miller, netdev
Cc: Andy Shevchenko
The rest of Hyper-V code is using new types for UUID handling.
Convert hv_sock as well.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
net/vmw_vsock/hyperv_transport.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index f2084e3f7aa4..2a1719c0f8d2 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -77,11 +77,11 @@ struct hvs_send_buf {
VMBUS_PKT_TRAILER_SIZE)
union hvs_service_id {
- uuid_le srv_id;
+ guid_t srv_id;
struct {
unsigned int svm_port;
- unsigned char b[sizeof(uuid_le) - sizeof(unsigned int)];
+ unsigned char b[sizeof(guid_t) - sizeof(unsigned int)];
};
};
@@ -89,8 +89,8 @@ union hvs_service_id {
struct hvsock {
struct vsock_sock *vsk;
- uuid_le vm_srv_id;
- uuid_le host_srv_id;
+ guid_t vm_srv_id;
+ guid_t host_srv_id;
struct vmbus_channel *chan;
struct vmpacket_descriptor *recv_desc;
@@ -159,21 +159,21 @@ struct hvsock {
#define MIN_HOST_EPHEMERAL_PORT (MAX_HOST_LISTEN_PORT + 1)
/* 00000000-facb-11e6-bd58-64006a7986d3 */
-static const uuid_le srv_id_template =
- UUID_LE(0x00000000, 0xfacb, 0x11e6, 0xbd, 0x58,
- 0x64, 0x00, 0x6a, 0x79, 0x86, 0xd3);
+static const guid_t srv_id_template =
+ GUID_INIT(0x00000000, 0xfacb, 0x11e6, 0xbd, 0x58,
+ 0x64, 0x00, 0x6a, 0x79, 0x86, 0xd3);
-static bool is_valid_srv_id(const uuid_le *id)
+static bool is_valid_srv_id(const guid_t *id)
{
- return !memcmp(&id->b[4], &srv_id_template.b[4], sizeof(uuid_le) - 4);
+ return !memcmp(&id->b[4], &srv_id_template.b[4], sizeof(guid_t) - 4);
}
-static unsigned int get_port_by_srv_id(const uuid_le *svr_id)
+static unsigned int get_port_by_srv_id(const guid_t *svr_id)
{
return *((unsigned int *)svr_id);
}
-static void hvs_addr_init(struct sockaddr_vm *addr, const uuid_le *svr_id)
+static void hvs_addr_init(struct sockaddr_vm *addr, const guid_t *svr_id)
{
unsigned int port = get_port_by_srv_id(svr_id);
@@ -316,7 +316,7 @@ static void hvs_close_connection(struct vmbus_channel *chan)
static void hvs_open_connection(struct vmbus_channel *chan)
{
- uuid_le *if_instance, *if_type;
+ guid_t *if_instance, *if_type;
unsigned char conn_from_host;
struct sockaddr_vm addr;
--
2.20.1
^ permalink raw reply related
* Re: memory leak in rds_send_probe
From: santosh.shilimkar @ 2019-07-23 16:48 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot, David Miller, netdev, linux-rdma,
rds-devel
Cc: LKML, syzkaller-bugs
In-Reply-To: <CACT4Y+a7eGJpsrenA-0RbWmwktDj5+XV4xaTeU+fiL5KXNbrqg@mail.gmail.com>
On 7/23/19 9:19 AM, Dmitry Vyukov wrote:
> On Tue, Jul 23, 2019 at 6:18 PM syzbot
> <syzbot+5134cdf021c4ed5aaa5f@syzkaller.appspotmail.com> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: c6dd78fc Merge branch 'x86-urgent-for-linus' of git://git...
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=14be98c8600000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=8de7d700ea5ac607
>> dashboard link: https://syzkaller.appspot.com/bug?extid=5134cdf021c4ed5aaa5f
>> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=145df0c8600000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=170001f4600000
>
> +net/rds/message.c maintainers
>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+5134cdf021c4ed5aaa5f@syzkaller.appspotmail.com
>>
>> BUG: memory leak
>> unreferenced object 0xffff8881234e9c00 (size 512):
Thanks for reporting. We will look into it.
>> comm "kworker/u4:2", pid 286, jiffies 4294948041 (age 7.750s)
>> hex dump (first 32 bytes):
>> 01 00 00 00 00 00 00 00 08 9c 4e 23 81 88 ff ff ..........N#....
>> 08 9c 4e 23 81 88 ff ff 18 9c 4e 23 81 88 ff ff ..N#......N#....
>> backtrace:
>> [<0000000032e378fa>] kmemleak_alloc_recursive
>> /./include/linux/kmemleak.h:43 [inline]
>> [<0000000032e378fa>] slab_post_alloc_hook /mm/slab.h:522 [inline]
>> [<0000000032e378fa>] slab_alloc /mm/slab.c:3319 [inline]
>> [<0000000032e378fa>] __do_kmalloc /mm/slab.c:3653 [inline]
>> [<0000000032e378fa>] __kmalloc+0x16d/0x2d0 /mm/slab.c:3664
>> [<0000000015bc9536>] kmalloc /./include/linux/slab.h:557 [inline]
>> [<0000000015bc9536>] kzalloc /./include/linux/slab.h:748 [inline]
>> [<0000000015bc9536>] rds_message_alloc+0x3e/0xc0 /net/rds/message.c:291
>> [<00000000a806d18d>] rds_send_probe.constprop.0+0x42/0x2f0
>> /net/rds/send.c:1419
>> [<00000000794a00cc>] rds_send_pong+0x1e/0x23 /net/rds/send.c:1482
>> [<00000000b2a248d0>] rds_recv_incoming+0x27e/0x460 /net/rds/recv.c:343
>> [<00000000ea1503db>] rds_loop_xmit+0x86/0x100 /net/rds/loop.c:96
>> [<00000000a9857f5a>] rds_send_xmit+0x524/0x9a0 /net/rds/send.c:355
>> [<00000000557b0101>] rds_send_worker+0x3c/0xd0 /net/rds/threads.c:200
>> [<000000004ba94868>] process_one_work+0x23f/0x490
>> /kernel/workqueue.c:2269
>> [<00000000e793f811>] worker_thread+0x195/0x580 /kernel/workqueue.c:2415
>> [<000000003ee8c1a1>] kthread+0x13e/0x160 /kernel/kthread.c:255
>> [<000000004cd53c81>] ret_from_fork+0x1f/0x30
>> /arch/x86/entry/entry_64.S:352
>>
>>
>>
>> ---
>> This bug is generated by a bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for more information about syzbot.
>> syzbot engineers can be reached at syzkaller@googlegroups.com.
>>
>> syzbot will keep track of this bug report. See:
>> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>> syzbot can test patches for this bug, for details see:
>> https://goo.gl/tpsmEJ#testing-patches
>>
>> --
>> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/000000000000ad1dfe058e5b89ab%40google.com.
^ permalink raw reply
* RE: [PATCH v1] hv_sock: Use consistent types for UUIDs
From: Dexuan Cui @ 2019-07-23 16:57 UTC (permalink / raw)
To: Andy Shevchenko, Haiyang Zhang, KY Srinivasan, Stephen Hemminger,
Sasha Levin, linux-hyperv@vger.kernel.org, David S. Miller,
netdev@vger.kernel.org
In-Reply-To: <20190723163943.65991-1-andriy.shevchenko@linux.intel.com>
> From: linux-hyperv-owner@vger.kernel.org
> <linux-hyperv-owner@vger.kernel.org> On Behalf Of Andy Shevchenko
> Sent: Tuesday, July 23, 2019 9:40 AM
>
> The rest of Hyper-V code is using new types for UUID handling.
> Convert hv_sock as well.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Looks good to me. Thanks, Andy!
Thanks,
-- Dexuan
^ permalink raw reply
* Re: [PATCH net 2/2] lib/dim: Fix -Wunused-const-variable warnings
From: Saeed Mahameed @ 2019-07-23 17:05 UTC (permalink / raw)
To: cai@lca.pw, davem@davemloft.net, leon@kernel.org
Cc: Jason Gunthorpe, Yamin Friedman, linux-rdma@vger.kernel.org,
Tal Gilboa, Leon Romanovsky, dledford@redhat.com,
netdev@vger.kernel.org
In-Reply-To: <20190723072248.6844-3-leon@kernel.org>
On Tue, 2019-07-23 at 10:22 +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> DIM causes to the following warnings during kernel compilation
> which indicates that tx_profile and rx_profile are supposed to
> be declared in *.c and not in *.h files.
>
> In file included from ./include/rdma/ib_verbs.h:64,
> from ./include/linux/mlx5/device.h:37,
> from ./include/linux/mlx5/driver.h:51,
> from ./include/linux/mlx5/vport.h:36,
> from drivers/infiniband/hw/mlx5/ib_virt.c:34:
> ./include/linux/dim.h:326:1: warning: _tx_profile_ defined but not
> used [-Wunused-const-variable=]
> 326 |
> tx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = {
> | ^~~~~~~~~~
> ./include/linux/dim.h:320:1: warning: _rx_profile_ defined but not
> used [-Wunused-const-variable=]
> 320 |
> rx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = {
> | ^~~~~~~~~~
>
> Fixes: 4f75da3666c0 ("linux/dim: Move implementation to .c files")
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
A similar patch was already submitted to linux-kernel ML,
"[PATCH] linux/dim: fix -Wunused-const-variable warnings"
I basically asked Qian to do the same as you did in this patch.
Anyway i guess it is ok to drop that patch and keep this one.
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
> ---
> include/linux/dim.h | 56 -----------------------------------------
> ----
> lib/dim/net_dim.c | 56
> +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 56 insertions(+), 56 deletions(-)
>
> diff --git a/include/linux/dim.h b/include/linux/dim.h
> index d3a0fbfff2bb..9fa4b3f88c39 100644
> --- a/include/linux/dim.h
> +++ b/include/linux/dim.h
> @@ -272,62 +272,6 @@ dim_update_sample_with_comps(u16 event_ctr, u64
> packets, u64 bytes, u64 comps,
>
> /* Net DIM */
>
> -/*
> - * Net DIM profiles:
> - * There are different set of profiles for each CQ period
> mode.
> - * There are different set of profiles for RX/TX CQs.
> - * Each profile size must be of NET_DIM_PARAMS_NUM_PROFILES
> - */
> -#define NET_DIM_PARAMS_NUM_PROFILES 5
> -#define NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE 256
> -#define NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE 128
> -#define NET_DIM_DEF_PROFILE_CQE 1
> -#define NET_DIM_DEF_PROFILE_EQE 1
> -
> -#define NET_DIM_RX_EQE_PROFILES { \
> - {1, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> - {8, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> - {64, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> - {128, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> - {256, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> -}
> -
> -#define NET_DIM_RX_CQE_PROFILES { \
> - {2, 256}, \
> - {8, 128}, \
> - {16, 64}, \
> - {32, 64}, \
> - {64, 64} \
> -}
> -
> -#define NET_DIM_TX_EQE_PROFILES { \
> - {1, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> - {8, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> - {32, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> - {64, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> - {128, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE} \
> -}
> -
> -#define NET_DIM_TX_CQE_PROFILES { \
> - {5, 128}, \
> - {8, 64}, \
> - {16, 32}, \
> - {32, 32}, \
> - {64, 32} \
> -}
> -
> -static const struct dim_cq_moder
> -rx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = {
> - NET_DIM_RX_EQE_PROFILES,
> - NET_DIM_RX_CQE_PROFILES,
> -};
> -
> -static const struct dim_cq_moder
> -tx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = {
> - NET_DIM_TX_EQE_PROFILES,
> - NET_DIM_TX_CQE_PROFILES,
> -};
> -
> /**
> * net_dim_get_rx_moderation - provide a CQ moderation object for
> the given RX profile
> * @cq_period_mode: CQ period mode
> diff --git a/lib/dim/net_dim.c b/lib/dim/net_dim.c
> index 5bcc902c5388..a4db51c21266 100644
> --- a/lib/dim/net_dim.c
> +++ b/lib/dim/net_dim.c
> @@ -5,6 +5,62 @@
>
> #include <linux/dim.h>
>
> +/*
> + * Net DIM profiles:
> + * There are different set of profiles for each CQ period
> mode.
> + * There are different set of profiles for RX/TX CQs.
> + * Each profile size must be of NET_DIM_PARAMS_NUM_PROFILES
> + */
> +#define NET_DIM_PARAMS_NUM_PROFILES 5
> +#define NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE 256
> +#define NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE 128
> +#define NET_DIM_DEF_PROFILE_CQE 1
> +#define NET_DIM_DEF_PROFILE_EQE 1
> +
> +#define NET_DIM_RX_EQE_PROFILES { \
> + {1, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> + {8, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> + {64, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> + {128, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> + {256, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> +}
> +
> +#define NET_DIM_RX_CQE_PROFILES { \
> + {2, 256}, \
> + {8, 128}, \
> + {16, 64}, \
> + {32, 64}, \
> + {64, 64} \
> +}
> +
> +#define NET_DIM_TX_EQE_PROFILES { \
> + {1, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> + {8, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> + {32, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> + {64, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> + {128, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE} \
> +}
> +
> +#define NET_DIM_TX_CQE_PROFILES { \
> + {5, 128}, \
> + {8, 64}, \
> + {16, 32}, \
> + {32, 32}, \
> + {64, 32} \
> +}
> +
> +static const struct dim_cq_moder
> +rx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = {
> + NET_DIM_RX_EQE_PROFILES,
> + NET_DIM_RX_CQE_PROFILES,
> +};
> +
> +static const struct dim_cq_moder
> +tx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = {
> + NET_DIM_TX_EQE_PROFILES,
> + NET_DIM_TX_CQE_PROFILES,
> +};
> +
> struct dim_cq_moder
> net_dim_get_rx_moderation(u8 cq_period_mode, int ix)
> {
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH net 1/2] linux/dim: Fix overflow in dim calculation
From: Saeed Mahameed @ 2019-07-23 17:22 UTC (permalink / raw)
To: davem@davemloft.net, leon@kernel.org
Cc: Jason Gunthorpe, Yamin Friedman, linux-rdma@vger.kernel.org,
Tal Gilboa, Leon Romanovsky, dledford@redhat.com,
netdev@vger.kernel.org
In-Reply-To: <20190723072248.6844-2-leon@kernel.org>
On Tue, 2019-07-23 at 10:22 +0300, Leon Romanovsky wrote:
> From: Yamin Friedman <yaminf@mellanox.com>
>
> While using net_dim, a dim_sample was used without ever initializing
> the
> comps value. Added use of DIV_ROUND_DOWN_ULL() to prevent potential
> overflow, it should not be a problem to save the final result in an
> int
> because after the division by epms the value should not be larger
> than a
> few thousand.
>
> [ 1040.127124] UBSAN: Undefined behaviour in lib/dim/dim.c:78:23
> [ 1040.130118] signed integer overflow:
> [ 1040.131643] 134718714 * 100 cannot be represented in type 'int'
>
> Fixes: 398c2b05bbee ("linux/dim: Add completions count to
> dim_sample")
> Signed-off-by: Yamin Friedman <yaminf@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> drivers/net/ethernet/broadcom/bcmsysport.c | 2 +-
> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 2 +-
> drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 4 ++--
> lib/dim/dim.c | 4 ++--
> 5 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c
> b/drivers/net/ethernet/broadcom/bcmsysport.c
> index b9c5cea8db16..9483553ce444 100644
> --- a/drivers/net/ethernet/broadcom/bcmsysport.c
> +++ b/drivers/net/ethernet/broadcom/bcmsysport.c
> @@ -992,7 +992,7 @@ static int bcm_sysport_poll(struct napi_struct
> *napi, int budget)
> {
> struct bcm_sysport_priv *priv =
> container_of(napi, struct bcm_sysport_priv, napi);
> - struct dim_sample dim_sample;
> + struct dim_sample dim_sample = {};
net_dim implementation doesn't care about sample->comp_ctr, so this is
unnecessary for the sake of fixing the rdma overflow issue, but it
doens't hurt anyone to have this change in this patch, although Tariq
already sent me a fix that i applied to my internal queues.
> unsigned int work_done = 0;
>
> work_done = bcm_sysport_desc_rx(priv, budget);
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> index 7134d2c3eb1c..7070349915bc 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> @@ -2136,7 +2136,7 @@ static int bnxt_poll(struct napi_struct *napi,
> int budget)
> }
> }
> if (bp->flags & BNXT_FLAG_DIM) {
> - struct dim_sample dim_sample;
> + struct dim_sample dim_sample = {};
>
> dim_update_sample(cpr->event_ctr,
> cpr->rx_packets,
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index a2b57807453b..d3a0b614dbfa 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -1895,7 +1895,7 @@ static int bcmgenet_rx_poll(struct napi_struct
> *napi, int budget)
> {
> struct bcmgenet_rx_ring *ring = container_of(napi,
> struct bcmgenet_rx_ring, napi);
> - struct dim_sample dim_sample;
> + struct dim_sample dim_sample = {};
> unsigned int work_done;
>
> work_done = bcmgenet_desc_rx(ring, budget);
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c
> b/drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c
> index c50b6f0769c8..49b06b256c92 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c
> @@ -49,7 +49,7 @@ static inline bool
> mlx5e_channel_no_affinity_change(struct mlx5e_channel *c)
> static void mlx5e_handle_tx_dim(struct mlx5e_txqsq *sq)
> {
> struct mlx5e_sq_stats *stats = sq->stats;
> - struct dim_sample dim_sample;
> + struct dim_sample dim_sample = {};
>
> if (unlikely(!test_bit(MLX5E_SQ_STATE_AM, &sq->state)))
> return;
> @@ -61,7 +61,7 @@ static void mlx5e_handle_tx_dim(struct mlx5e_txqsq
> *sq)
> static void mlx5e_handle_rx_dim(struct mlx5e_rq *rq)
> {
> struct mlx5e_rq_stats *stats = rq->stats;
> - struct dim_sample dim_sample;
> + struct dim_sample dim_sample = {};
>
> if (unlikely(!test_bit(MLX5E_RQ_STATE_AM, &rq->state)))
> return;
> diff --git a/lib/dim/dim.c b/lib/dim/dim.c
> index 439d641ec796..38045d6d0538 100644
> --- a/lib/dim/dim.c
> +++ b/lib/dim/dim.c
> @@ -74,8 +74,8 @@ void dim_calc_stats(struct dim_sample *start,
> struct dim_sample *end,
> delta_us);
> curr_stats->cpms = DIV_ROUND_UP(ncomps * USEC_PER_MSEC,
> delta_us);
> if (curr_stats->epms != 0)
BTW unrelated to this changed but curr_stats->epms can never be 0 due
to DIV_ROUND_UP. we can save a condition here.
> - curr_stats->cpe_ratio =
> - (curr_stats->cpms * 100) / curr_stats-
> >epms;
> + curr_stats->cpe_ratio = DIV_ROUND_DOWN_ULL(
> + curr_stats->cpms * 100, curr_stats->epms);
> else
> curr_stats->cpe_ratio = 0;
>
LGTM,
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
> --
> 2.20.1
>
^ permalink raw reply
* Re: Re: kernel panic: stack is corrupted in pointer
From: syzbot @ 2019-07-23 17:26 UTC (permalink / raw)
To: John Fastabend
Cc: airlied, alexander.deucher, amd-gfx, ast, bpf, christian.koenig,
daniel, david1.zhou, dri-devel, dvyukov, john.fastabend, leo.liu,
linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <5d37433a832d_3aba2ae4f6ec05bc3a@john-XPS-13-9370.notmuch>
> Dmitry Vyukov wrote:
>> On Wed, Jul 17, 2019 at 10:58 AM syzbot
>> <syzbot+79f5f028005a77ecb6bb@syzkaller.appspotmail.com> wrote:
>> >
>> > Hello,
>> >
>> > syzbot found the following crash on:
>> >
>> > HEAD commit: 1438cde7 Add linux-next specific files for 20190716
>> > git tree: linux-next
>> > console output:
>> https://syzkaller.appspot.com/x/log.txt?x=13988058600000
>> > kernel config:
>> https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
>> > dashboard link:
>> https://syzkaller.appspot.com/bug?extid=79f5f028005a77ecb6bb
>> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>> > syz repro:
>> https://syzkaller.appspot.com/x/repro.syz?x=111fc8afa00000
>> From the repro it looks like the same bpf stack overflow bug. +John
>> We need to dup them onto some canonical report for this bug, or this
>> becomes unmanageable.
> Fixes in bpf tree should fix this. Hopefully, we will squash this once
> fixes
> percolate up.
> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
">" does not look like a valid git branch or commit.
>> #syz dup: kernel panic: corrupted stack end in dput
>> > The bug was bisected to:
>> >
>> > commit 96a5d8d4915f3e241ebb48d5decdd110ab9c7dcf
>> > Author: Leo Liu <leo.liu@amd.com>
>> > Date: Fri Jul 13 15:26:28 2018 +0000
>> >
>> > drm/amdgpu: Make sure IB tests flushed after IP resume
>> >
>> > bisection log:
>> https://syzkaller.appspot.com/x/bisect.txt?x=14a46200600000
>> > final crash:
>> https://syzkaller.appspot.com/x/report.txt?x=16a46200600000
>> > console output:
>> https://syzkaller.appspot.com/x/log.txt?x=12a46200600000
>> >
>> > IMPORTANT: if you fix the bug, please add the following tag to the
>> commit:
>> > Reported-by: syzbot+79f5f028005a77ecb6bb@syzkaller.appspotmail.com
>> > Fixes: 96a5d8d4915f ("drm/amdgpu: Make sure IB tests flushed after IP
>> > resume")
>> >
>> > Kernel panic - not syncing: stack-protector: Kernel stack is corrupted
>> in:
>> > pointer+0x702/0x750 lib/vsprintf.c:2187
>> > Shutting down cpus with NMI
>> > Kernel Offset: disabled
>> >
>> >
>> > ---
>> > This bug is generated by a bot. It may contain errors.
>> > See https://goo.gl/tpsmEJ for more information about syzbot.
>> > syzbot engineers can be reached at syzkaller@googlegroups.com.
>> >
>> > syzbot will keep track of this bug report. See:
>> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>> > For information about bisection process see:
>> https://goo.gl/tpsmEJ#bisection
>> > syzbot can test patches for this bug, for details see:
>> > https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: kernel panic: stack is corrupted in pointer
From: John Fastabend @ 2019-07-23 17:26 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot, John Fastabend, bpf
Cc: David Airlie, alexander.deucher, amd-gfx, Alexei Starovoitov,
christian.koenig, Daniel Borkmann, david1.zhou, DRI, leo.liu,
LKML, netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+ZGwKP+f4esJdx60AywO9b3Y5Bxb4zLtH6EEkaHpP6Zag@mail.gmail.com>
Dmitry Vyukov wrote:
> On Wed, Jul 17, 2019 at 10:58 AM syzbot
> <syzbot+79f5f028005a77ecb6bb@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 1438cde7 Add linux-next specific files for 20190716
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=13988058600000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
> > dashboard link: https://syzkaller.appspot.com/bug?extid=79f5f028005a77ecb6bb
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=111fc8afa00000
>
> From the repro it looks like the same bpf stack overflow bug. +John
> We need to dup them onto some canonical report for this bug, or this
> becomes unmanageable.
Fixes in bpf tree should fix this. Hopefully, we will squash this once fixes
percolate up.
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
>
> #syz dup: kernel panic: corrupted stack end in dput
>
> > The bug was bisected to:
> >
> > commit 96a5d8d4915f3e241ebb48d5decdd110ab9c7dcf
> > Author: Leo Liu <leo.liu@amd.com>
> > Date: Fri Jul 13 15:26:28 2018 +0000
> >
> > drm/amdgpu: Make sure IB tests flushed after IP resume
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14a46200600000
> > final crash: https://syzkaller.appspot.com/x/report.txt?x=16a46200600000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=12a46200600000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+79f5f028005a77ecb6bb@syzkaller.appspotmail.com
> > Fixes: 96a5d8d4915f ("drm/amdgpu: Make sure IB tests flushed after IP
> > resume")
> >
> > Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
> > pointer+0x702/0x750 lib/vsprintf.c:2187
> > Shutting down cpus with NMI
> > Kernel Offset: disabled
> >
> >
> > ---
> > This bug is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> > syzbot can test patches for this bug, for details see:
> > https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH net-next] dpaa2-eth: Don't use netif_receive_skb_list for TCP frames
From: Ioana Radulescu @ 2019-07-23 17:28 UTC (permalink / raw)
To: netdev, davem; +Cc: ioana.ciornei, vladimir.oltean
Using Rx skb bulking for all frames may negatively impact the
performance in some TCP termination scenarios, as it effectively
bypasses GRO.
Look at the hardware parse results of each ingress frame to see
if a TCP header is present or not; for TCP frames fall back to
the old implementation.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 15 ++++++-
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h | 51 ++++++++++++++++++++++++
2 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
index 0acb115..412f87f 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
@@ -348,6 +348,16 @@ static u32 run_xdp(struct dpaa2_eth_priv *priv,
return xdp_act;
}
+static bool frame_is_tcp(const struct dpaa2_fd *fd, struct dpaa2_fas *fas)
+{
+ struct dpaa2_fapr *fapr = dpaa2_get_fapr(fas, false);
+
+ if (!(dpaa2_fd_get_frc(fd) & DPAA2_FD_FRC_FAPRV))
+ return false;
+
+ return !!(fapr->faf_hi & DPAA2_FAF_HI_TCP_PRESENT);
+}
+
/* Main Rx frame processing routine */
static void dpaa2_eth_rx(struct dpaa2_eth_priv *priv,
struct dpaa2_eth_channel *ch,
@@ -435,7 +445,10 @@ static void dpaa2_eth_rx(struct dpaa2_eth_priv *priv,
percpu_stats->rx_packets++;
percpu_stats->rx_bytes += dpaa2_fd_get_len(fd);
- list_add_tail(&skb->list, ch->rx_list);
+ if (frame_is_tcp(fd, fas))
+ napi_gro_receive(&ch->napi, skb);
+ else
+ list_add_tail(&skb->list, ch->rx_list);
return;
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
index 9af18c2..d723ae7 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
@@ -155,6 +155,49 @@ struct dpaa2_fas {
*/
#define DPAA2_TS_OFFSET 0x8
+/* Frame annotation parse results */
+struct dpaa2_fapr {
+ /* 64-bit word 1 */
+ __le32 faf_lo;
+ __le16 faf_ext;
+ __le16 nxt_hdr;
+ /* 64-bit word 2 */
+ __le64 faf_hi;
+ /* 64-bit word 3 */
+ u8 last_ethertype_offset;
+ u8 vlan_tci_offset_n;
+ u8 vlan_tci_offset_1;
+ u8 llc_snap_offset;
+ u8 eth_offset;
+ u8 ip1_pid_offset;
+ u8 shim_offset_2;
+ u8 shim_offset_1;
+ /* 64-bit word 4 */
+ u8 l5_offset;
+ u8 l4_offset;
+ u8 gre_offset;
+ u8 l3_offset_n;
+ u8 l3_offset_1;
+ u8 mpls_offset_n;
+ u8 mpls_offset_1;
+ u8 pppoe_offset;
+ /* 64-bit word 5 */
+ __le16 running_sum;
+ __le16 gross_running_sum;
+ u8 ipv6_frag_offset;
+ u8 nxt_hdr_offset;
+ u8 routing_hdr_offset_2;
+ u8 routing_hdr_offset_1;
+ /* 64-bit word 6 */
+ u8 reserved[5]; /* Soft-parsing context */
+ u8 ip_proto_offset_n;
+ u8 nxt_hdr_frag_offset;
+ u8 parse_error_code;
+};
+
+#define DPAA2_FAPR_OFFSET 0x10
+#define DPAA2_FAPR_SIZE sizeof((struct dpaa2_fapr))
+
/* Frame annotation egress action descriptor */
#define DPAA2_FAEAD_OFFSET 0x58
@@ -185,6 +228,11 @@ static inline __le64 *dpaa2_get_ts(void *buf_addr, bool swa)
return dpaa2_get_hwa(buf_addr, swa) + DPAA2_TS_OFFSET;
}
+static inline struct dpaa2_fapr *dpaa2_get_fapr(void *buf_addr, bool swa)
+{
+ return dpaa2_get_hwa(buf_addr, swa) + DPAA2_FAPR_OFFSET;
+}
+
static inline struct dpaa2_faead *dpaa2_get_faead(void *buf_addr, bool swa)
{
return dpaa2_get_hwa(buf_addr, swa) + DPAA2_FAEAD_OFFSET;
@@ -236,6 +284,9 @@ static inline struct dpaa2_faead *dpaa2_get_faead(void *buf_addr, bool swa)
DPAA2_FAS_L3CE | \
DPAA2_FAS_L4CE)
+/* TCP indication in Frame Annotation Parse Results */
+#define DPAA2_FAF_HI_TCP_PRESENT BIT(23)
+
/* Time in milliseconds between link state updates */
#define DPAA2_ETH_LINK_STATE_REFRESH 1000
--
2.7.4
^ permalink raw reply related
* Re: [PATCH bpf-next] libbpf: provide more helpful message on uninitialized global var
From: Andrii Nakryiko @ 2019-07-23 17:33 UTC (permalink / raw)
To: Song Liu
Cc: Andrii Nakryiko, bpf@vger.kernel.org, netdev@vger.kernel.org,
Alexei Starovoitov, daniel@iogearbox.net, Kernel Team
In-Reply-To: <ECB3771E-B6E8-45EC-B673-A0E0F79340BF@fb.com>
On Tue, Jul 23, 2019 at 1:51 AM Song Liu <songliubraving@fb.com> wrote:
>
>
>
> > On Jul 22, 2019, at 9:23 PM, Andrii Nakryiko <andriin@fb.com> wrote:
> >
> > When BPF program defines uninitialized global variable, it's put into
> > a special COMMON section. Libbpf will reject such programs, but will
> > provide very unhelpful message with garbage-looking section index.
> >
> > This patch detects special section cases and gives more explicit error
> > message.
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > tools/lib/bpf/libbpf.c | 14 +++++++++++---
> > 1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index 794dd5064ae8..5f9e7eedb134 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -1760,15 +1760,23 @@ bpf_program__collect_reloc(struct bpf_program *prog, GElf_Shdr *shdr,
> > (long long) sym.st_value, sym.st_name, name);
> >
> > shdr_idx = sym.st_shndx;
> > + insn_idx = rel.r_offset / sizeof(struct bpf_insn);
> > + pr_debug("relocation: insn_idx=%u, shdr_idx=%u\n",
> > + insn_idx, shdr_idx);
> > +
> > + if (shdr_idx >= SHN_LORESERVE) {
> > + pr_warning("relocation: not yet supported relo for non-static global \'%s\' variable "
> > + "in special section (0x%x) found in insns[%d].code 0x%x\n",
>
> For easy grep, we should keep this one long long string.
I was worried it's way too long, so split it. But yeah, I'll just
merge it back into single line, thanks!
>
> Thanks,
> Song
^ permalink raw reply
* Re: Re: kernel panic: stack is corrupted in pointer
From: John Fastabend @ 2019-07-23 17:33 UTC (permalink / raw)
To: syzbot, John Fastabend
Cc: airlied, alexander.deucher, amd-gfx, ast, bpf, christian.koenig,
daniel, david1.zhou, dri-devel, dvyukov, john.fastabend, leo.liu,
linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <0000000000002cec2e058e5c7e63@google.com>
syzbot wrote:
> > Dmitry Vyukov wrote:
> >> On Wed, Jul 17, 2019 at 10:58 AM syzbot
> >> <syzbot+79f5f028005a77ecb6bb@syzkaller.appspotmail.com> wrote:
> >> >
> >> > Hello,
> >> >
> >> > syzbot found the following crash on:
> >> >
> >> > HEAD commit: 1438cde7 Add linux-next specific files for 20190716
> >> > git tree: linux-next
> >> > console output:
> >> https://syzkaller.appspot.com/x/log.txt?x=13988058600000
> >> > kernel config:
> >> https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
> >> > dashboard link:
> >> https://syzkaller.appspot.com/bug?extid=79f5f028005a77ecb6bb
> >> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> >> > syz repro:
> >> https://syzkaller.appspot.com/x/repro.syz?x=111fc8afa00000
>
> >> From the repro it looks like the same bpf stack overflow bug. +John
> >> We need to dup them onto some canonical report for this bug, or this
> >> becomes unmanageable.
>
> > Fixes in bpf tree should fix this. Hopefully, we will squash this once
> > fixes
> > percolate up.
>
> > #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
>
> ">" does not look like a valid git branch or commit.
>
try again,
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git master
^ permalink raw reply
* [net-next 0/6][pull request] 1GbE Intel Wired LAN Driver Updates 2019-07-23
From: Jeff Kirsher @ 2019-07-23 17:36 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann
This series contains updates to igc and e1000e client drivers only.
Sasha provides a couple of cleanups to remove code that is not needed
and reduce structure sizes. Updated the MAC reset flow to use the
device reset flow instead of a port reset flow. Added addition device
id's that will be supported.
Kai-Heng Feng provides a workaround for a possible stalled packet issue
in our ICH devices due to a clock recovery from the PCH being too slow.
Also provided a fix where the MAC & PHY may become de-sync'd causing a
miss detection of link up events.
The following are changes since commit d5c3a62d0bb9b763e9378fe8f4cd79502e16cce8:
Merge branch 'Convert-skb_frag_t-to-bio_vec'
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 1GbE
Kai-Heng Feng (2):
e1000e: add workaround for possible stalled packet
e1000e: disable force K1-off feature
Sasha Neftin (4):
igc: Remove the polarity field from a PHY information structure
igc: Remove the unused field from a device specification structure
igc: Update the MAC reset flow
igc: Add more SKUs for i225 device
drivers/net/ethernet/intel/e1000e/hw.h | 1 +
drivers/net/ethernet/intel/e1000e/ich8lan.c | 13 +++++++++++++
drivers/net/ethernet/intel/e1000e/ich8lan.h | 2 +-
drivers/net/ethernet/intel/igc/igc_base.c | 5 ++++-
drivers/net/ethernet/intel/igc/igc_defines.h | 2 +-
drivers/net/ethernet/intel/igc/igc_hw.h | 14 +++-----------
drivers/net/ethernet/intel/igc/igc_main.c | 3 +++
7 files changed, 26 insertions(+), 14 deletions(-)
--
2.21.0
^ permalink raw reply
* [net-next 2/6] igc: Remove the unused field from a device specification structure
From: Jeff Kirsher @ 2019-07-23 17:36 UTC (permalink / raw)
To: davem; +Cc: Sasha Neftin, netdev, nhorman, sassmann, Aaron Brown,
Jeff Kirsher
In-Reply-To: <20190723173650.23276-1-jeffrey.t.kirsher@intel.com>
From: Sasha Neftin <sasha.neftin@intel.com>
This patch comes to clean up the device specification structure.
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igc/igc_hw.h | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_hw.h b/drivers/net/ethernet/intel/igc/igc_hw.h
index f689f0a02b5d..9a338fbf671c 100644
--- a/drivers/net/ethernet/intel/igc/igc_hw.h
+++ b/drivers/net/ethernet/intel/igc/igc_hw.h
@@ -184,12 +184,7 @@ struct igc_fc_info {
};
struct igc_dev_spec_base {
- bool global_device_reset;
- bool eee_disable;
bool clear_semaphore_once;
- bool module_plugged;
- u8 media_port;
- bool mas_capable;
};
struct igc_hw {
--
2.21.0
^ permalink raw reply related
* [net-next 3/6] igc: Update the MAC reset flow
From: Jeff Kirsher @ 2019-07-23 17:36 UTC (permalink / raw)
To: davem; +Cc: Sasha Neftin, netdev, nhorman, sassmann, Aaron Brown,
Jeff Kirsher
In-Reply-To: <20190723173650.23276-1-jeffrey.t.kirsher@intel.com>
From: Sasha Neftin <sasha.neftin@intel.com>
Use Device Reset flow instead of Port Reset flow.
This flow performs a reset of the entire controller device,
resulting in a state nearly approximating the state
following a power-up reset or internal PCIe reset,
except for system PCI configuration.
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igc/igc_base.c | 2 +-
drivers/net/ethernet/intel/igc/igc_defines.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_base.c b/drivers/net/ethernet/intel/igc/igc_base.c
index 59258d791106..46206b3dabfb 100644
--- a/drivers/net/ethernet/intel/igc/igc_base.c
+++ b/drivers/net/ethernet/intel/igc/igc_base.c
@@ -40,7 +40,7 @@ static s32 igc_reset_hw_base(struct igc_hw *hw)
ctrl = rd32(IGC_CTRL);
hw_dbg("Issuing a global reset to MAC\n");
- wr32(IGC_CTRL, ctrl | IGC_CTRL_RST);
+ wr32(IGC_CTRL, ctrl | IGC_CTRL_DEV_RST);
ret_val = igc_get_auto_rd_done(hw);
if (ret_val) {
diff --git a/drivers/net/ethernet/intel/igc/igc_defines.h b/drivers/net/ethernet/intel/igc/igc_defines.h
index fc0ccfe38a20..11b99acf4abe 100644
--- a/drivers/net/ethernet/intel/igc/igc_defines.h
+++ b/drivers/net/ethernet/intel/igc/igc_defines.h
@@ -54,7 +54,7 @@
#define IGC_ERR_SWFW_SYNC 13
/* Device Control */
-#define IGC_CTRL_RST 0x04000000 /* Global reset */
+#define IGC_CTRL_DEV_RST 0x20000000 /* Device reset */
#define IGC_CTRL_PHY_RST 0x80000000 /* PHY Reset */
#define IGC_CTRL_SLU 0x00000040 /* Set link up (Force Link) */
--
2.21.0
^ permalink raw reply related
* [net-next 4/6] igc: Add more SKUs for i225 device
From: Jeff Kirsher @ 2019-07-23 17:36 UTC (permalink / raw)
To: davem; +Cc: Sasha Neftin, netdev, nhorman, sassmann, Aaron Brown,
Jeff Kirsher
In-Reply-To: <20190723173650.23276-1-jeffrey.t.kirsher@intel.com>
From: Sasha Neftin <sasha.neftin@intel.com>
Add support for more SKUs.
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igc/igc_base.c | 3 +++
drivers/net/ethernet/intel/igc/igc_hw.h | 3 +++
drivers/net/ethernet/intel/igc/igc_main.c | 3 +++
3 files changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/intel/igc/igc_base.c b/drivers/net/ethernet/intel/igc/igc_base.c
index 46206b3dabfb..db289bcce21d 100644
--- a/drivers/net/ethernet/intel/igc/igc_base.c
+++ b/drivers/net/ethernet/intel/igc/igc_base.c
@@ -209,6 +209,9 @@ static s32 igc_get_invariants_base(struct igc_hw *hw)
switch (hw->device_id) {
case IGC_DEV_ID_I225_LM:
case IGC_DEV_ID_I225_V:
+ case IGC_DEV_ID_I225_I:
+ case IGC_DEV_ID_I220_V:
+ case IGC_DEV_ID_I225_K:
mac->type = igc_i225;
break;
default:
diff --git a/drivers/net/ethernet/intel/igc/igc_hw.h b/drivers/net/ethernet/intel/igc/igc_hw.h
index 9a338fbf671c..abb2d72911ff 100644
--- a/drivers/net/ethernet/intel/igc/igc_hw.h
+++ b/drivers/net/ethernet/intel/igc/igc_hw.h
@@ -18,6 +18,9 @@
#define IGC_DEV_ID_I225_LM 0x15F2
#define IGC_DEV_ID_I225_V 0x15F3
+#define IGC_DEV_ID_I225_I 0x15F8
+#define IGC_DEV_ID_I220_V 0x15F7
+#define IGC_DEV_ID_I225_K 0x3100
#define IGC_FUNC_0 0
diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
index 9ffe71424ece..e5114bebd30b 100644
--- a/drivers/net/ethernet/intel/igc/igc_main.c
+++ b/drivers/net/ethernet/intel/igc/igc_main.c
@@ -36,6 +36,9 @@ static const struct igc_info *igc_info_tbl[] = {
static const struct pci_device_id igc_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, IGC_DEV_ID_I225_LM), board_base },
{ PCI_VDEVICE(INTEL, IGC_DEV_ID_I225_V), board_base },
+ { PCI_VDEVICE(INTEL, IGC_DEV_ID_I225_I), board_base },
+ { PCI_VDEVICE(INTEL, IGC_DEV_ID_I220_V), board_base },
+ { PCI_VDEVICE(INTEL, IGC_DEV_ID_I225_K), board_base },
/* required last entry */
{0, }
};
--
2.21.0
^ permalink raw reply related
* [net-next 6/6] e1000e: disable force K1-off feature
From: Jeff Kirsher @ 2019-07-23 17:36 UTC (permalink / raw)
To: davem; +Cc: Kai-Heng Feng, netdev, nhorman, sassmann, Aaron Brown,
Jeff Kirsher
In-Reply-To: <20190723173650.23276-1-jeffrey.t.kirsher@intel.com>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
MAC-PHY desync may occur causing miss detection of link up event.
Disabling K1-off feature can work around the problem.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000e/hw.h | 1 +
drivers/net/ethernet/intel/e1000e/ich8lan.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/hw.h b/drivers/net/ethernet/intel/e1000e/hw.h
index eff75bd8a8f0..e3c71fd093ee 100644
--- a/drivers/net/ethernet/intel/e1000e/hw.h
+++ b/drivers/net/ethernet/intel/e1000e/hw.h
@@ -662,6 +662,7 @@ struct e1000_dev_spec_ich8lan {
bool kmrn_lock_loss_workaround_enabled;
struct e1000_shadow_ram shadow_ram[E1000_ICH8_SHADOW_RAM_WORDS];
bool nvm_k1_enabled;
+ bool disable_k1_off;
bool eee_disable;
u16 eee_lp_ability;
enum e1000_ulp_state ulp_state;
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index a1fab77b2096..6a9a4014f4b7 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -1538,6 +1538,9 @@ static s32 e1000_check_for_copper_link_ich8lan(struct e1000_hw *hw)
fextnvm6 &= ~E1000_FEXTNVM6_K1_OFF_ENABLE;
}
+ if (hw->dev_spec.ich8lan.disable_k1_off == true)
+ fextnvm6 &= ~E1000_FEXTNVM6_K1_OFF_ENABLE;
+
ew32(FEXTNVM6, fextnvm6);
}
--
2.21.0
^ permalink raw reply related
* [net-next 5/6] e1000e: add workaround for possible stalled packet
From: Jeff Kirsher @ 2019-07-23 17:36 UTC (permalink / raw)
To: davem; +Cc: Kai-Heng Feng, netdev, nhorman, sassmann, Aaron Brown,
Jeff Kirsher
In-Reply-To: <20190723173650.23276-1-jeffrey.t.kirsher@intel.com>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
This works around a possible stalled packet issue, which may occur due to
clock recovery from the PCH being too slow, when the LAN is transitioning
from K1 at 1G link speed.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 10 ++++++++++
drivers/net/ethernet/intel/e1000e/ich8lan.h | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 395b05701480..a1fab77b2096 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -1429,6 +1429,16 @@ static s32 e1000_check_for_copper_link_ich8lan(struct e1000_hw *hw)
else
phy_reg |= 0xFA;
e1e_wphy_locked(hw, I217_PLL_CLOCK_GATE_REG, phy_reg);
+
+ if (speed == SPEED_1000) {
+ hw->phy.ops.read_reg_locked(hw, HV_PM_CTRL,
+ &phy_reg);
+
+ phy_reg |= HV_PM_CTRL_K1_CLK_REQ;
+
+ hw->phy.ops.write_reg_locked(hw, HV_PM_CTRL,
+ phy_reg);
+ }
}
hw->phy.ops.release(hw);
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.h b/drivers/net/ethernet/intel/e1000e/ich8lan.h
index eb09c755fa17..1502895eb45d 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.h
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.h
@@ -210,7 +210,7 @@
/* PHY Power Management Control */
#define HV_PM_CTRL PHY_REG(770, 17)
-#define HV_PM_CTRL_PLL_STOP_IN_K1_GIGA 0x100
+#define HV_PM_CTRL_K1_CLK_REQ 0x200
#define HV_PM_CTRL_K1_ENABLE 0x4000
#define I217_PLL_CLOCK_GATE_REG PHY_REG(772, 28)
--
2.21.0
^ permalink raw reply related
* [net-next 1/6] igc: Remove the polarity field from a PHY information structure
From: Jeff Kirsher @ 2019-07-23 17:36 UTC (permalink / raw)
To: davem; +Cc: Sasha Neftin, netdev, nhorman, sassmann, Aaron Brown,
Jeff Kirsher
In-Reply-To: <20190723173650.23276-1-jeffrey.t.kirsher@intel.com>
From: Sasha Neftin <sasha.neftin@intel.com>
Polarity and cable length fields is not applicable for the i225 device.
This patch comes to clean up PHY information structure.
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igc/igc_hw.h | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_hw.h b/drivers/net/ethernet/intel/igc/igc_hw.h
index 1039a224ac80..f689f0a02b5d 100644
--- a/drivers/net/ethernet/intel/igc/igc_hw.h
+++ b/drivers/net/ethernet/intel/igc/igc_hw.h
@@ -151,16 +151,10 @@ struct igc_phy_info {
u16 autoneg_advertised;
u16 autoneg_mask;
- u16 cable_length;
- u16 max_cable_length;
- u16 min_cable_length;
- u16 pair_length[4];
u8 mdix;
- bool disable_polarity_correction;
bool is_mdix;
- bool polarity_correction;
bool reset_disable;
bool speed_downgraded;
bool autoneg_wait_to_complete;
--
2.21.0
^ permalink raw reply related
* Re: [PATCH bpf-next 1/5] selftests/bpf: convert test_get_stack_raw_tp to perf_buffer API
From: Andrii Nakryiko @ 2019-07-23 17:38 UTC (permalink / raw)
To: Song Liu
Cc: Andrii Nakryiko, bpf, netdev@vger.kernel.org, Alexei Starovoitov,
daniel@iogearbox.net, Kernel Team
In-Reply-To: <EBDB05E7-C10F-479F-B2A7-62D59EE4887E@fb.com>
On Tue, Jul 23, 2019 at 2:25 AM Song Liu <songliubraving@fb.com> wrote:
>
>
>
> > On Jul 22, 2019, at 9:31 PM, Andrii Nakryiko <andriin@fb.com> wrote:
> >
> > Convert test_get_stack_raw_tp test to new perf_buffer API.
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > .../bpf/prog_tests/get_stack_raw_tp.c | 78 ++++++++++---------
> > .../bpf/progs/test_get_stack_rawtp.c | 2 +-
> > 2 files changed, 44 insertions(+), 36 deletions(-)
> >
> > diff --git a/tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c b/tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c
> > index c2a0a9d5591b..473889e1b219 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c
> > @@ -1,8 +1,15 @@
> > // SPDX-License-Identifier: GPL-2.0
> > +#define _GNU_SOURCE
> > +#include <pthread.h>
> > +#include <sched.h>
> > +#include <sys/socket.h>
> > #include <test_progs.h>
> >
> > #define MAX_CNT_RAWTP 10ull
> > #define MAX_STACK_RAWTP 100
> > +
> > +static int duration = 0;
> > +
>
> Are we using "duration" at all?
Yes, unfortunately in test_progs CHECK macro expects "duration"
variable to be defined. It's very annoying and I'm going to work on
cleaning up and streamlining how we do selftests in bpf, so hopefully
we'll get rid of some of those "artifacts". But for now, yeah,
duration has to be defined somewhere.
>
> > struct get_stack_trace_t {
> > int pid;
> > int kern_stack_size;
> > @@ -13,7 +20,7 @@ struct get_stack_trace_t {
> > struct bpf_stack_build_id user_stack_buildid[MAX_STACK_RAWTP];
> > };
> >
> > -static int get_stack_print_output(void *data, int size)
> > +static void get_stack_print_output(void *ctx, int cpu, void *data, __u32 size)
> > {
> > bool good_kern_stack = false, good_user_stack = false;
> > const char *nonjit_func = "___bpf_prog_run";
> > @@ -65,75 +72,76 @@ static int get_stack_print_output(void *data, int size)
> > if (e->user_stack_size > 0 && e->user_stack_buildid_size > 0)
> > good_user_stack = true;
> > }
> > - if (!good_kern_stack || !good_user_stack)
> > - return LIBBPF_PERF_EVENT_ERROR;
> >
> > - if (cnt == MAX_CNT_RAWTP)
> > - return LIBBPF_PERF_EVENT_DONE;
> > -
> > - return LIBBPF_PERF_EVENT_CONT;
> > + if (!good_kern_stack)
> > + CHECK(!good_kern_stack, "bad_kern_stack", "bad\n");
>
> Two "bad" is a little weird. How about "kern stack", "bad"?
Heh :) I'll add something more human-readable, like "failed to get
kernel stack".
>
> > + if (!good_user_stack)
> > + CHECK(!good_user_stack, "bad_user_stack", "bad\n");
> > }
> >
> > void test_get_stack_raw_tp(void)
> > {
[...]
^ permalink raw reply
* Re: [patch iproute2 1/2] tc: action: fix crash caused by incorrect *argv check
From: Stephen Hemminger @ 2019-07-23 17:47 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, sthemmin, dsahern, alexanderk, mlxsw
In-Reply-To: <20190723112538.10977-1-jiri@resnulli.us>
On Tue, 23 Jul 2019 13:25:37 +0200
Jiri Pirko <jiri@resnulli.us> wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> One cannot depend on *argv being null in case of no arg is left on the
> command line. For example in batch mode, this is not always true. Check
> argc instead to prevent crash.
>
> Reported-by: Alex Kushnarov <alexanderk@mellanox.com>
> Fixes: fd8b3d2c1b9b ("actions: Add support for user cookies")
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> tc/m_action.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tc/m_action.c b/tc/m_action.c
> index ab6bc0ad28ff..0f9c3a27795d 100644
> --- a/tc/m_action.c
> +++ b/tc/m_action.c
> @@ -222,7 +222,7 @@ done0:
> goto bad_val;
> }
>
> - if (*argv && strcmp(*argv, "cookie") == 0) {
> + if (argc && strcmp(*argv, "cookie") == 0) {
> size_t slen;
>
> NEXT_ARG();
Ok, but we should also fix batch mode to null last argv
^ permalink raw reply
* Re: [patch iproute2 1/2] tc: action: fix crash caused by incorrect *argv check
From: Stephen Hemminger @ 2019-07-23 17:54 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, sthemmin, dsahern, alexanderk, mlxsw
In-Reply-To: <20190723112538.10977-1-jiri@resnulli.us>
On Tue, 23 Jul 2019 13:25:37 +0200
Jiri Pirko <jiri@resnulli.us> wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> One cannot depend on *argv being null in case of no arg is left on the
> command line. For example in batch mode, this is not always true. Check
> argc instead to prevent crash.
>
> Reported-by: Alex Kushnarov <alexanderk@mellanox.com>
> Fixes: fd8b3d2c1b9b ("actions: Add support for user cookies")
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Actually makeargs does NULL terminate the last arg so what input
to batchmode is breaking this?
^ permalink raw reply
* Re: [PATCH net-next] dpaa2-eth: Don't use netif_receive_skb_list for TCP frames
From: Saeed Mahameed @ 2019-07-23 17:54 UTC (permalink / raw)
To: ruxandra.radulescu@nxp.com, netdev@vger.kernel.org,
davem@davemloft.net
Cc: ioana.ciornei@nxp.com, vladimir.oltean@nxp.com
In-Reply-To: <1563902923-26178-1-git-send-email-ruxandra.radulescu@nxp.com>
On Tue, 2019-07-23 at 20:28 +0300, Ioana Radulescu wrote:
> Using Rx skb bulking for all frames may negatively impact the
> performance in some TCP termination scenarios, as it effectively
> bypasses GRO.
>
> Look at the hardware parse results of each ingress frame to see
> if a TCP header is present or not; for TCP frames fall back to
> the old implementation.
>
> Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 15 ++++++-
> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h | 51
> ++++++++++++++++++++++++
> 2 files changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
> b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
> index 0acb115..412f87f 100644
> --- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
> @@ -348,6 +348,16 @@ static u32 run_xdp(struct dpaa2_eth_priv *priv,
> return xdp_act;
> }
>
> +static bool frame_is_tcp(const struct dpaa2_fd *fd, struct dpaa2_fas
> *fas)
> +{
> + struct dpaa2_fapr *fapr = dpaa2_get_fapr(fas, false);
> +
> + if (!(dpaa2_fd_get_frc(fd) & DPAA2_FD_FRC_FAPRV))
> + return false;
> +
> + return !!(fapr->faf_hi & DPAA2_FAF_HI_TCP_PRESENT);
> +}
> +
> /* Main Rx frame processing routine */
> static void dpaa2_eth_rx(struct dpaa2_eth_priv *priv,
> struct dpaa2_eth_channel *ch,
> @@ -435,7 +445,10 @@ static void dpaa2_eth_rx(struct dpaa2_eth_priv
> *priv,
> percpu_stats->rx_packets++;
> percpu_stats->rx_bytes += dpaa2_fd_get_len(fd);
>
> - list_add_tail(&skb->list, ch->rx_list);
> + if (frame_is_tcp(fd, fas))
> + napi_gro_receive(&ch->napi, skb);
> + else
> + list_add_tail(&skb->list, ch->rx_list);
>
Maybe it is better if we introduce napi_gro_receive_list()
and let napi decide when to do napi_gro_receive or list_add_tail, gro
stack already knows how to make the decision, (no need to have a
specialized hw parser for TCP frames) so all drivers will benefit from
this and we will not repeat the same thing you did here in all
drivers.
also in such case napi/napi_gro will maintain the temporary rx skb
list, which seems more natural than implementing it per driver.
On napi_gro_receive_list:
1) Try gro
2) if the result is GRO_NORMAL, then add the skb to list
3) on napi_complete or when list budget is consumed flush skb list by
calling netif_receive_skb_list.
> return;
>
> diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
> b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
> index 9af18c2..d723ae7 100644
> --- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
> +++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
> @@ -155,6 +155,49 @@ struct dpaa2_fas {
> */
> #define DPAA2_TS_OFFSET 0x8
>
> +/* Frame annotation parse results */
> +struct dpaa2_fapr {
> + /* 64-bit word 1 */
> + __le32 faf_lo;
> + __le16 faf_ext;
> + __le16 nxt_hdr;
> + /* 64-bit word 2 */
> + __le64 faf_hi;
> + /* 64-bit word 3 */
> + u8 last_ethertype_offset;
> + u8 vlan_tci_offset_n;
> + u8 vlan_tci_offset_1;
> + u8 llc_snap_offset;
> + u8 eth_offset;
> + u8 ip1_pid_offset;
> + u8 shim_offset_2;
> + u8 shim_offset_1;
> + /* 64-bit word 4 */
> + u8 l5_offset;
> + u8 l4_offset;
> + u8 gre_offset;
> + u8 l3_offset_n;
> + u8 l3_offset_1;
> + u8 mpls_offset_n;
> + u8 mpls_offset_1;
> + u8 pppoe_offset;
> + /* 64-bit word 5 */
> + __le16 running_sum;
> + __le16 gross_running_sum;
> + u8 ipv6_frag_offset;
> + u8 nxt_hdr_offset;
> + u8 routing_hdr_offset_2;
> + u8 routing_hdr_offset_1;
> + /* 64-bit word 6 */
> + u8 reserved[5]; /* Soft-parsing context */
> + u8 ip_proto_offset_n;
> + u8 nxt_hdr_frag_offset;
> + u8 parse_error_code;
> +};
> +
> +#define DPAA2_FAPR_OFFSET 0x10
> +#define DPAA2_FAPR_SIZE sizeof((struct
> dpaa2_fapr))
> +
> /* Frame annotation egress action descriptor */
> #define DPAA2_FAEAD_OFFSET 0x58
>
> @@ -185,6 +228,11 @@ static inline __le64 *dpaa2_get_ts(void
> *buf_addr, bool swa)
> return dpaa2_get_hwa(buf_addr, swa) + DPAA2_TS_OFFSET;
> }
>
> +static inline struct dpaa2_fapr *dpaa2_get_fapr(void *buf_addr, bool
> swa)
> +{
> + return dpaa2_get_hwa(buf_addr, swa) + DPAA2_FAPR_OFFSET;
> +}
> +
> static inline struct dpaa2_faead *dpaa2_get_faead(void *buf_addr,
> bool swa)
> {
> return dpaa2_get_hwa(buf_addr, swa) + DPAA2_FAEAD_OFFSET;
> @@ -236,6 +284,9 @@ static inline struct dpaa2_faead
> *dpaa2_get_faead(void *buf_addr, bool swa)
> DPAA2_FAS_L3CE | \
> DPAA2_FAS_L4CE)
>
> +/* TCP indication in Frame Annotation Parse Results */
> +#define DPAA2_FAF_HI_TCP_PRESENT BIT(23)
> +
> /* Time in milliseconds between link state updates */
> #define DPAA2_ETH_LINK_STATE_REFRESH 1000
>
^ permalink raw reply
* Re: [PATCH net 2/2] lib/dim: Fix -Wunused-const-variable warnings
From: Leon Romanovsky @ 2019-07-23 18:01 UTC (permalink / raw)
To: Saeed Mahameed
Cc: cai@lca.pw, davem@davemloft.net, Jason Gunthorpe, Yamin Friedman,
linux-rdma@vger.kernel.org, Tal Gilboa, dledford@redhat.com,
netdev@vger.kernel.org
In-Reply-To: <63328bfc11778eb851773872aa30d15796a428d9.camel@mellanox.com>
On Tue, Jul 23, 2019 at 05:05:19PM +0000, Saeed Mahameed wrote:
> On Tue, 2019-07-23 at 10:22 +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > DIM causes to the following warnings during kernel compilation
> > which indicates that tx_profile and rx_profile are supposed to
> > be declared in *.c and not in *.h files.
> >
> > In file included from ./include/rdma/ib_verbs.h:64,
> > from ./include/linux/mlx5/device.h:37,
> > from ./include/linux/mlx5/driver.h:51,
> > from ./include/linux/mlx5/vport.h:36,
> > from drivers/infiniband/hw/mlx5/ib_virt.c:34:
> > ./include/linux/dim.h:326:1: warning: _tx_profile_ defined but not
> > used [-Wunused-const-variable=]
> > 326 |
> > tx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = {
> > | ^~~~~~~~~~
> > ./include/linux/dim.h:320:1: warning: _rx_profile_ defined but not
> > used [-Wunused-const-variable=]
> > 320 |
> > rx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = {
> > | ^~~~~~~~~~
> >
> > Fixes: 4f75da3666c0 ("linux/dim: Move implementation to .c files")
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
>
> A similar patch was already submitted to linux-kernel ML,
> "[PATCH] linux/dim: fix -Wunused-const-variable warnings"
Are you talking about this merged patch? If yes, it was incomplete.
ommit bedc0fd0f9b517698193d644f914b33951856fd2
Author: Qian Cai <cai@lca.pw>
Date: Thu Jul 11 09:55:56 2019 -0400
RDMA/core: Fix -Wunused-const-variable warnings
>
> I basically asked Qian to do the same as you did in this patch.
> Anyway i guess it is ok to drop that patch and keep this one.
>
> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
>
> > ---
> > include/linux/dim.h | 56 -----------------------------------------
> > ----
> > lib/dim/net_dim.c | 56
> > +++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 56 insertions(+), 56 deletions(-)
> >
> > diff --git a/include/linux/dim.h b/include/linux/dim.h
> > index d3a0fbfff2bb..9fa4b3f88c39 100644
> > --- a/include/linux/dim.h
> > +++ b/include/linux/dim.h
> > @@ -272,62 +272,6 @@ dim_update_sample_with_comps(u16 event_ctr, u64
> > packets, u64 bytes, u64 comps,
> >
> > /* Net DIM */
> >
> > -/*
> > - * Net DIM profiles:
> > - * There are different set of profiles for each CQ period
> > mode.
> > - * There are different set of profiles for RX/TX CQs.
> > - * Each profile size must be of NET_DIM_PARAMS_NUM_PROFILES
> > - */
> > -#define NET_DIM_PARAMS_NUM_PROFILES 5
> > -#define NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE 256
> > -#define NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE 128
> > -#define NET_DIM_DEF_PROFILE_CQE 1
> > -#define NET_DIM_DEF_PROFILE_EQE 1
> > -
> > -#define NET_DIM_RX_EQE_PROFILES { \
> > - {1, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > - {8, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > - {64, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > - {128, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > - {256, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > -}
> > -
> > -#define NET_DIM_RX_CQE_PROFILES { \
> > - {2, 256}, \
> > - {8, 128}, \
> > - {16, 64}, \
> > - {32, 64}, \
> > - {64, 64} \
> > -}
> > -
> > -#define NET_DIM_TX_EQE_PROFILES { \
> > - {1, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > - {8, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > - {32, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > - {64, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > - {128, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE} \
> > -}
> > -
> > -#define NET_DIM_TX_CQE_PROFILES { \
> > - {5, 128}, \
> > - {8, 64}, \
> > - {16, 32}, \
> > - {32, 32}, \
> > - {64, 32} \
> > -}
> > -
> > -static const struct dim_cq_moder
> > -rx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = {
> > - NET_DIM_RX_EQE_PROFILES,
> > - NET_DIM_RX_CQE_PROFILES,
> > -};
> > -
> > -static const struct dim_cq_moder
> > -tx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = {
> > - NET_DIM_TX_EQE_PROFILES,
> > - NET_DIM_TX_CQE_PROFILES,
> > -};
> > -
> > /**
> > * net_dim_get_rx_moderation - provide a CQ moderation object for
> > the given RX profile
> > * @cq_period_mode: CQ period mode
> > diff --git a/lib/dim/net_dim.c b/lib/dim/net_dim.c
> > index 5bcc902c5388..a4db51c21266 100644
> > --- a/lib/dim/net_dim.c
> > +++ b/lib/dim/net_dim.c
> > @@ -5,6 +5,62 @@
> >
> > #include <linux/dim.h>
> >
> > +/*
> > + * Net DIM profiles:
> > + * There are different set of profiles for each CQ period
> > mode.
> > + * There are different set of profiles for RX/TX CQs.
> > + * Each profile size must be of NET_DIM_PARAMS_NUM_PROFILES
> > + */
> > +#define NET_DIM_PARAMS_NUM_PROFILES 5
> > +#define NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE 256
> > +#define NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE 128
> > +#define NET_DIM_DEF_PROFILE_CQE 1
> > +#define NET_DIM_DEF_PROFILE_EQE 1
> > +
> > +#define NET_DIM_RX_EQE_PROFILES { \
> > + {1, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > + {8, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > + {64, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > + {128, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > + {256, NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > +}
> > +
> > +#define NET_DIM_RX_CQE_PROFILES { \
> > + {2, 256}, \
> > + {8, 128}, \
> > + {16, 64}, \
> > + {32, 64}, \
> > + {64, 64} \
> > +}
> > +
> > +#define NET_DIM_TX_EQE_PROFILES { \
> > + {1, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > + {8, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > + {32, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > + {64, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE}, \
> > + {128, NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE} \
> > +}
> > +
> > +#define NET_DIM_TX_CQE_PROFILES { \
> > + {5, 128}, \
> > + {8, 64}, \
> > + {16, 32}, \
> > + {32, 32}, \
> > + {64, 32} \
> > +}
> > +
> > +static const struct dim_cq_moder
> > +rx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = {
> > + NET_DIM_RX_EQE_PROFILES,
> > + NET_DIM_RX_CQE_PROFILES,
> > +};
> > +
> > +static const struct dim_cq_moder
> > +tx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = {
> > + NET_DIM_TX_EQE_PROFILES,
> > + NET_DIM_TX_CQE_PROFILES,
> > +};
> > +
> > struct dim_cq_moder
> > net_dim_get_rx_moderation(u8 cq_period_mode, int ix)
> > {
> > --
> > 2.20.1
> >
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] netlink: add validation of NLA_F_NESTED flag
From: Stephen Hemminger @ 2019-07-23 18:02 UTC (permalink / raw)
To: Michal Kubecek
Cc: David S. Miller, netdev, Johannes Berg, David Ahern, linux-kernel
In-Reply-To: <6b6ead21c5d8436470b82ab40355f6bd7dbbf14b.1556806084.git.mkubecek@suse.cz>
On Thu, 2 May 2019 16:15:10 +0200 (CEST)
Michal Kubecek <mkubecek@suse.cz> wrote:
> Add new validation flag NL_VALIDATE_NESTED which adds three consistency
> checks of NLA_F_NESTED_FLAG:
>
> - the flag is set on attributes with NLA_NESTED{,_ARRAY} policy
> - the flag is not set on attributes with other policies except NLA_UNSPEC
> - the flag is set on attribute passed to nla_parse_nested()
>
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
>
> v2: change error messages to mention NLA_F_NESTED explicitly
There are some cases where netlink related to IPv4 does not send nested
flag. You risk breaking older iproute2 and other tools being used on newer
kernel. I.e this patch may break binary compatibility. Have you tried running
with this on a very old distro (like Redhat Linux 9)?
^ permalink raw reply
* Re: [PATCH net 1/2] linux/dim: Fix overflow in dim calculation
From: Leon Romanovsky @ 2019-07-23 18:04 UTC (permalink / raw)
To: Saeed Mahameed
Cc: davem@davemloft.net, Jason Gunthorpe, Yamin Friedman,
linux-rdma@vger.kernel.org, Tal Gilboa, dledford@redhat.com,
netdev@vger.kernel.org
In-Reply-To: <4f4bc2958dc1512087f19db64e8e43f1247cf2dd.camel@mellanox.com>
On Tue, Jul 23, 2019 at 05:22:43PM +0000, Saeed Mahameed wrote:
> On Tue, 2019-07-23 at 10:22 +0300, Leon Romanovsky wrote:
> > From: Yamin Friedman <yaminf@mellanox.com>
> >
> > While using net_dim, a dim_sample was used without ever initializing
> > the
> > comps value. Added use of DIV_ROUND_DOWN_ULL() to prevent potential
> > overflow, it should not be a problem to save the final result in an
> > int
> > because after the division by epms the value should not be larger
> > than a
> > few thousand.
> >
> > [ 1040.127124] UBSAN: Undefined behaviour in lib/dim/dim.c:78:23
> > [ 1040.130118] signed integer overflow:
> > [ 1040.131643] 134718714 * 100 cannot be represented in type 'int'
> >
> > Fixes: 398c2b05bbee ("linux/dim: Add completions count to
> > dim_sample")
> > Signed-off-by: Yamin Friedman <yaminf@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > ---
> > drivers/net/ethernet/broadcom/bcmsysport.c | 2 +-
> > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
> > drivers/net/ethernet/broadcom/genet/bcmgenet.c | 2 +-
> > drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 4 ++--
> > lib/dim/dim.c | 4 ++--
> > 5 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c
> > b/drivers/net/ethernet/broadcom/bcmsysport.c
> > index b9c5cea8db16..9483553ce444 100644
> > --- a/drivers/net/ethernet/broadcom/bcmsysport.c
> > +++ b/drivers/net/ethernet/broadcom/bcmsysport.c
> > @@ -992,7 +992,7 @@ static int bcm_sysport_poll(struct napi_struct
> > *napi, int budget)
> > {
> > struct bcm_sysport_priv *priv =
> > container_of(napi, struct bcm_sysport_priv, napi);
> > - struct dim_sample dim_sample;
> > + struct dim_sample dim_sample = {};
>
> net_dim implementation doesn't care about sample->comp_ctr, so this is
> unnecessary for the sake of fixing the rdma overflow issue, but it
> doens't hurt anyone to have this change in this patch.
Yes, this is why we decided to change all drivers and not mlx5 only.
Thanks
^ 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