* Re: [PATCH 1/2] net-ipv4: remove 2 always zero parameters from ipv4_update_pmtu()
From: David Ahern @ 2018-09-26 0:52 UTC (permalink / raw)
To: Maciej Żenczykowski, Maciej Żenczykowski,
David S . Miller, Eric Dumazet
Cc: netdev
In-Reply-To: <20180926004137.163699-1-zenczykowski@gmail.com>
On 9/25/18 6:41 PM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski <maze@google.com>
>
A summary here of which 2 parameters are always 0 would be nice.
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> ---
> include/net/route.h | 2 +-
> net/ipv4/ah4.c | 2 +-
> net/ipv4/esp4.c | 2 +-
> net/ipv4/icmp.c | 2 +-
> net/ipv4/ip_gre.c | 2 +-
> net/ipv4/ip_vti.c | 2 +-
> net/ipv4/ipcomp.c | 2 +-
> net/ipv4/ipip.c | 3 +--
> net/ipv4/route.c | 8 +++-----
> net/ipv6/sit.c | 2 +-
> net/netfilter/ipvs/ip_vs_core.c | 3 +--
> net/xfrm/xfrm_interface.c | 2 +-
> 12 files changed, 14 insertions(+), 18 deletions(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/2] net-ipv4: remove 2 always zero parameters from ipv4_redirect()
From: David Ahern @ 2018-09-26 0:52 UTC (permalink / raw)
To: Maciej Żenczykowski, Maciej Żenczykowski,
David S . Miller, Eric Dumazet
Cc: netdev
In-Reply-To: <20180926004137.163699-2-zenczykowski@gmail.com>
On 9/25/18 6:41 PM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski <maze@google.com>
A summary here of which 2 parameters are always 0 would be nice.
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> ---
> include/net/route.h | 3 +--
> net/ipv4/ah4.c | 2 +-
> net/ipv4/esp4.c | 2 +-
> net/ipv4/icmp.c | 2 +-
> net/ipv4/ip_gre.c | 4 ++--
> net/ipv4/ip_vti.c | 2 +-
> net/ipv4/ipcomp.c | 2 +-
> net/ipv4/ipip.c | 2 +-
> net/ipv4/route.c | 4 ++--
> net/ipv6/sit.c | 4 ++--
> net/xfrm/xfrm_interface.c | 2 +-
> 11 files changed, 14 insertions(+), 15 deletions(-)
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: Grant-
From: M. M. Fridman @ 2018-09-25 21:25 UTC (permalink / raw)
To: Recipients
I, Mikhail Fridman have selected you specifically as one of my beneficiaries
for my Charitable Donation, just as I have declared on 23rd of May 2016 to give
my fortune to charity.
Check the link below for confirmation:
https://www.rt.com/business/343781-mikhail-fridman-will-charity/
Reply as soon as possible with further directives.
Best Regards,
Mikhail Fridman.
^ permalink raw reply
* WARNING in pfkey_sock_destruct
From: syzbot @ 2018-09-26 7:41 UTC (permalink / raw)
To: davem, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 10dc890d4228 Merge tag 'pinctrl-v4.19-3' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=126e7111400000
kernel config: https://syzkaller.appspot.com/x/.config?x=5fa12be50bca08d8
dashboard link: https://syzkaller.appspot.com/bug?extid=4acf0d9092f91bb60431
compiler: gcc (GCC) 8.0.1 20180413 (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+4acf0d9092f91bb60431@syzkaller.appspotmail.com
WARNING: CPU: 1 PID: 18415 at net/key/af_key.c:111
pfkey_sock_destruct+0x574/0x610 net/key/af_key.c:111
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 18415 Comm: syz-executor3 Not tainted 4.19.0-rc4+ #28
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+0x1c4/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
report_bug+0x254/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993
RIP: 0010:pfkey_sock_destruct+0x574/0x610 net/key/af_key.c:111
Code: 00 48 c7 c7 a0 14 b4 88 c6 05 9e 48 40 03 01 e8 6d bc 80 fa e9 70 fc
ff ff e8 78 69 9e fa 0f 0b e9 a8 fe ff ff e8 6c 69 9e fa <0f> 0b e9 ed fd
ff ff 48 89 c7 e8 2d ca e1 fa e9 40 fe ff ff 4c 89
RSP: 0018:ffff880199627660 EFLAGS: 00010293
RAX: ffff88011e2a0680 RBX: ffff8801c5053100 RCX: ffffffff86e078fa
RDX: 0000000000000000 RSI: ffffffff86e07b14 RDI: 0000000000000005
RBP: ffff880199627770 R08: ffff88011e2a0680 R09: ffffed0038a0a65b
R10: ffffed0038a0a65b R11: ffff8801c50532db R12: 1ffff100332c4ecd
R13: ffff880199627748 R14: 1ffff100332c4ed1 R15: ffff8801cd7d4b40
__sk_destruct+0x115/0xbd0 net/core/sock.c:1560
sk_destruct+0x78/0x90 net/core/sock.c:1595
__sk_free+0xcf/0x300 net/core/sock.c:1606
sk_free+0x42/0x50 net/core/sock.c:1617
sock_put include/net/sock.h:1691 [inline]
pfkey_release+0x409/0x570 net/key/af_key.c:194
__sock_release+0xd7/0x250 net/socket.c:579
sock_close+0x19/0x20 net/socket.c:1141
__fput+0x385/0xa30 fs/file_table.c:278
____fput+0x15/0x20 fs/file_table.c:309
task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:193 [inline]
exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x411151
Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 34 19 00 00 c3 48
83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48
89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
kobject: 'loop4' (000000003d24b0c2): kobject_uevent_env
RSP: 002b:00007ffd93469000 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
kobject: 'loop4' (000000003d24b0c2): fill_kobj_path: path
= '/devices/virtual/block/loop4'
RAX: 0000000000000000 RBX: 0000000000000006 RCX: 0000000000411151
RDX: 0000000000000000 RSI: 00000000007317f8 RDI: 0000000000000005
RBP: 0000000000000000 R08: 00000000000000a0 R09: ffffffffffffffff
R10: 000000000072bfa0 R11: 0000000000000293 R12: 000000000000000b
R13: 000000000006a9d7 R14: 0000000000000167 R15: badc0ffeebadface
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
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#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* general protection fault in integrity_inode_free
From: syzbot @ 2018-09-26 7:47 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 846e8dd47c26 Merge tag 'scsi-fixes' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12a59d56400000
kernel config: https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f
dashboard link: https://syzkaller.appspot.com/bug?extid=4c0fa7d385ea5af34e91
compiler: gcc (GCC) 8.0.1 20180413 (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+4c0fa7d385ea5af34e91@syzkaller.appspotmail.com
__do_sys_sendmsg net/socket.c:2163 [inline]
__se_sys_sendmsg net/socket.c:2161 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
entry_SYSCALL_64_after_hwframe+0x49/0xbe
general protection fault: 0000 [#1] PREEMPT SMP KASAN
RIP: 0033:0x457579
CPU: 0 PID: 8727 Comm: syz-executor3 Not tainted 4.19.0-rc5+ #33
Code: 1d b4 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RSP: 002b:00007f07f2e4bc78 EFLAGS: 00000246
RIP: 0010:__rb_erase_augmented include/linux/rbtree_augmented.h:168 [inline]
RIP: 0010:rb_erase+0x306/0x3710 lib/rbtree.c:459
ORIG_RAX: 000000000000002e
Code: c7 81 28 01 00 00 f2 f2 f2 f2 c7 81 2c 01 00 00 00 f2 f2 f2 48 89 f9
65 48 8b 1c 25 28 00 00 00 48 89 5d d0 31 db 48 c1 e9 03 <42> 80 3c 01 00
0f 85 41 1c 00 00 4c 8d 48 10 4c 8b 78 08 48 b9 00
RAX: ffffffffffffffda RBX: 00007f07f2e4bc90 RCX: 0000000000457579
RSP: 0018:ffff88018620e918 EFLAGS: 00010202
RDX: 0000000000000000 RSI: 000000002000b000 RDI: 0000000000000003
RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f07f2e4c6d4
RDX: 1ffff10030c41d2b RSI: ffffffff8b5a08a0 RDI: 0000000000000008
R13: 00000000004c38e1 R14: 00000000004d5730 R15: 0000000000000004
RBP: ffff88018620f320 R08: dffffc0000000000 R09: fffffbfff135d5c8
kobject: 'loop5' (00000000eac6d22a): kobject_uevent_env
R10: fffffbfff135d5c8 R11: ffffffff89aeae43 R12: ffff8801bacb38f0
R13: dffffc0000000000 R14: ffff88018620f2f8 R15: ffff88018620f438
overlayfs: unrecognized mount option "smackfstransmute=upperdir" or missing
value
FS: 00007ff9677ec700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31324000 CR3: 00000001c2773000 CR4: 00000000001406f0
Call Trace:
integrity_inode_free+0x12f/0x320 security/integrity/iint.c:150
security_inode_free+0x19/0x90 security/security.c:453
__destroy_inode+0x328/0x820 fs/inode.c:238
destroy_inode+0xda/0x200 fs/inode.c:265
evict+0x5e0/0x980 fs/inode.c:575
iput_final fs/inode.c:1547 [inline]
iput+0x679/0xa90 fs/inode.c:1573
swap_inode_boot_loader fs/ext4/ioctl.c:188 [inline]
ext4_ioctl+0x236f/0x4210 fs/ext4/ioctl.c:865
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:501 [inline]
do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
__do_sys_ioctl fs/ioctl.c:709 [inline]
__se_sys_ioctl fs/ioctl.c:707 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457579
Code: 1d b4 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ff9677ebc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 0000000000457579
RDX: 0000000000000000 RSI: 0000000000006611 RDI: 0000000000000003
RBP: 000000000072c040 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ff9677ec6d4
R13: 00000000004bf626 R14: 00000000004cf4c0 R15: 00000000ffffffff
Modules linked in:
---[ end trace 6d41a32e43d56085 ]---
RIP: 0010:__rb_erase_augmented include/linux/rbtree_augmented.h:168 [inline]
RIP: 0010:rb_erase+0x306/0x3710 lib/rbtree.c:459
Code: c7 81 28 01 00 00 f2 f2 f2 f2 c7 81 2c 01 00 00 00 f2 f2 f2 48 89 f9
65 48 8b 1c 25 28 00 00 00 48 89 5d d0 31 db 48 c1 e9 03 <42> 80 3c 01 00
0f 85 41 1c 00 00 4c 8d 48 10 4c 8b 78 08 48 b9 00
RSP: 0018:ffff88018620e918 EFLAGS: 00010202
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 1ffff10030c41d2b RSI: ffffffff8b5a08a0 RDI: 0000000000000008
RBP: ffff88018620f320 R08: dffffc0000000000 R09: fffffbfff135d5c8
R10: fffffbfff135d5c8 R11: ffffffff89aeae43 R12: ffff8801bacb38f0
R13: dffffc0000000000 R14: ffff88018620f2f8 R15: ffff88018620f438
FS: 00007ff9677ec700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31324000 CR3: 00000001c2773000 CR4: 00000000001406f0
---
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#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* KASAN: use-after-free Read in vhost_transport_cancel_pkt
From: syzbot @ 2018-09-26 7:50 UTC (permalink / raw)
To: jasowang, kvm, linux-kernel, mst, netdev, stefanha,
syzkaller-bugs, virtualization
Hello,
syzbot found the following crash on:
HEAD commit: 4ca719a338d5 Merge branch 'linus' of git://git.kernel.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16861f99400000
kernel config: https://syzkaller.appspot.com/x/.config?x=5fa12be50bca08d8
dashboard link: https://syzkaller.appspot.com/bug?extid=e3e074963495f92a89ed
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
userspace arch: i386
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+e3e074963495f92a89ed@syzkaller.appspotmail.com
QAT: Invalid ioctl
==================================================================
BUG: KASAN: use-after-free in perf_trace_lock_acquire+0x66b/0x800
include/trace/events/lock.h:13
Read of size 8 at addr ffff880196f584e8 by task syz-executor1/30556
CPU: 1 PID: 30556 Comm: syz-executor1 Not tainted 4.19.0-rc4+ #148
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+0x1c4/0x2b4 lib/dump_stack.c:113
print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
perf_trace_lock_acquire+0x66b/0x800 include/trace/events/lock.h:13
trace_lock_acquire include/trace/events/lock.h:13 [inline]
lock_acquire+0x385/0x520 kernel/locking/lockdep.c:3899
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
_raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
spin_lock_bh include/linux/spinlock.h:334 [inline]
vhost_transport_cancel_pkt+0x15e/0x910 drivers/vhost/vsock.c:244
vsock_transport_cancel_pkt net/vmw_vsock/af_vsock.c:1114 [inline]
vsock_stream_connect+0x903/0xe40 net/vmw_vsock/af_vsock.c:1241
__sys_connect+0x37d/0x4c0 net/socket.c:1664
__do_sys_connect net/socket.c:1675 [inline]
__se_sys_connect net/socket.c:1672 [inline]
__ia32_sys_connect+0x72/0xb0 net/socket.c:1672
do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7f8fca9
Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 0c 24 c3 8b 1c 24 c3 90 90
90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:00000000f5f280cc EFLAGS: 00000296 ORIG_RAX: 000000000000016a
RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 0000000020000080
RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Allocated by task 30547:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
__do_kmalloc_node mm/slab.c:3682 [inline]
__kmalloc_node+0x47/0x70 mm/slab.c:3689
kmalloc_node include/linux/slab.h:555 [inline]
kvmalloc_node+0xb9/0xf0 mm/util.c:423
QAT: Invalid ioctl
kvmalloc include/linux/mm.h:577 [inline]
vhost_vsock_dev_open+0xa2/0x5a0 drivers/vhost/vsock.c:511
misc_open+0x3ca/0x560 drivers/char/misc.c:141
chrdev_open+0x25a/0x710 fs/char_dev.c:417
do_dentry_open+0x499/0x1250 fs/open.c:771
vfs_open+0xa0/0xd0 fs/open.c:880
do_last fs/namei.c:3418 [inline]
path_openat+0x12bf/0x5160 fs/namei.c:3534
do_filp_open+0x255/0x380 fs/namei.c:3564
do_sys_open+0x568/0x700 fs/open.c:1063
__do_compat_sys_openat fs/open.c:1109 [inline]
__se_compat_sys_openat fs/open.c:1107 [inline]
__ia32_compat_sys_openat+0x98/0xf0 fs/open.c:1107
do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
Freed by task 30546:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xcf/0x230 mm/slab.c:3813
kvfree+0x61/0x70 mm/util.c:452
vhost_vsock_free drivers/vhost/vsock.c:499 [inline]
vhost_vsock_dev_release+0x4f4/0x720 drivers/vhost/vsock.c:604
__fput+0x385/0xa30 fs/file_table.c:278
____fput+0x15/0x20 fs/file_table.c:309
task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:193 [inline]
exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_32_irqs_on arch/x86/entry/common.c:341 [inline]
do_fast_syscall_32+0xcd5/0xfb2 arch/x86/entry/common.c:397
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
The buggy address belongs to the object at ffff880196f4f7c0
which belongs to the cache kmalloc-65536 of size 65536
The buggy address is located 36136 bytes inside of
65536-byte region [ffff880196f4f7c0, ffff880196f5f7c0)
The buggy address belongs to the page:
page:ffffea00065bd000 count:1 mapcount:0 mapping:ffff8801da802500 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea00071cf008 ffffea0007199808 ffff8801da802500
raw: 0000000000000000 ffff880196f4f7c0 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff880196f58380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880196f58400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff880196f58480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff880196f58500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880196f58580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
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#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* [PATCH resend] can: rcar_can: convert to SPDX identifiers
From: Kuninori Morimoto @ 2018-09-26 1:41 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: Linux-Renesas, Linux-Net, linux-can
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
This patch updates license to use SPDX-License-Identifier
instead of verbose license text.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
---
Wolfgang, Marc
2 weeks past, resend patch
drivers/net/can/rcar/Kconfig | 1 +
drivers/net/can/rcar/Makefile | 1 +
drivers/net/can/rcar/rcar_can.c | 6 +-----
drivers/net/can/rcar/rcar_canfd.c | 6 +-----
4 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/can/rcar/Kconfig b/drivers/net/can/rcar/Kconfig
index 7b03a3a..bd5a8fc 100644
--- a/drivers/net/can/rcar/Kconfig
+++ b/drivers/net/can/rcar/Kconfig
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
config CAN_RCAR
tristate "Renesas R-Car CAN controller"
depends on ARCH_RENESAS || ARM
diff --git a/drivers/net/can/rcar/Makefile b/drivers/net/can/rcar/Makefile
index 08de36a..c9185b0 100644
--- a/drivers/net/can/rcar/Makefile
+++ b/drivers/net/can/rcar/Makefile
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
#
# Makefile for the Renesas R-Car CAN & CAN FD controller drivers
#
diff --git a/drivers/net/can/rcar/rcar_can.c b/drivers/net/can/rcar/rcar_can.c
index 11662f4..06f90a0 100644
--- a/drivers/net/can/rcar/rcar_can.c
+++ b/drivers/net/can/rcar/rcar_can.c
@@ -1,12 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
/* Renesas R-Car CAN device driver
*
* Copyright (C) 2013 Cogent Embedded, Inc. <source@cogentembedded.com>
* Copyright (C) 2013 Renesas Solutions Corp.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
*/
#include <linux/module.h>
diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
index 602c19e..0541000 100644
--- a/drivers/net/can/rcar/rcar_canfd.c
+++ b/drivers/net/can/rcar/rcar_canfd.c
@@ -1,11 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
/* Renesas R-Car CAN FD device driver
*
* Copyright (C) 2015 Renesas Electronics Corp.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
*/
/* The R-Car CAN FD controller can operate in either one of the below two modes
--
2.7.4
^ permalink raw reply related
* Re: general protection fault in integrity_inode_free
From: Dmitry Vyukov @ 2018-09-26 7:53 UTC (permalink / raw)
To: syzbot, James Morris, Serge E. Hallyn, zohar, Matthew Garrett,
Dmitry Kasatkin, sudeep.holla, jlayton, linux-security-module
Cc: David Miller, LKML, netdev, syzkaller-bugs
In-Reply-To: <0000000000009581bf0576c16d3a@google.com>
On Wed, Sep 26, 2018 at 9:47 AM, syzbot
<syzbot+4c0fa7d385ea5af34e91@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 846e8dd47c26 Merge tag 'scsi-fixes' of git://git.kernel.or..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=12a59d56400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f
> dashboard link: https://syzkaller.appspot.com/bug?extid=4c0fa7d385ea5af34e91
> compiler: gcc (GCC) 8.0.1 20180413 (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+4c0fa7d385ea5af34e91@syzkaller.appspotmail.com
This was misattributed to net, +IMA maintainers.
> __do_sys_sendmsg net/socket.c:2163 [inline]
> __se_sys_sendmsg net/socket.c:2161 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> general protection fault: 0000 [#1] PREEMPT SMP KASAN
> RIP: 0033:0x457579
> CPU: 0 PID: 8727 Comm: syz-executor3 Not tainted 4.19.0-rc5+ #33
> Code: 1d b4 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RSP: 002b:00007f07f2e4bc78 EFLAGS: 00000246
> RIP: 0010:__rb_erase_augmented include/linux/rbtree_augmented.h:168 [inline]
> RIP: 0010:rb_erase+0x306/0x3710 lib/rbtree.c:459
> ORIG_RAX: 000000000000002e
> Code: c7 81 28 01 00 00 f2 f2 f2 f2 c7 81 2c 01 00 00 00 f2 f2 f2 48 89 f9
> 65 48 8b 1c 25 28 00 00 00 48 89 5d d0 31 db 48 c1 e9 03 <42> 80 3c 01 00 0f
> 85 41 1c 00 00 4c 8d 48 10 4c 8b 78 08 48 b9 00
> RAX: ffffffffffffffda RBX: 00007f07f2e4bc90 RCX: 0000000000457579
> RSP: 0018:ffff88018620e918 EFLAGS: 00010202
> RDX: 0000000000000000 RSI: 000000002000b000 RDI: 0000000000000003
> RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f07f2e4c6d4
> RDX: 1ffff10030c41d2b RSI: ffffffff8b5a08a0 RDI: 0000000000000008
> R13: 00000000004c38e1 R14: 00000000004d5730 R15: 0000000000000004
> RBP: ffff88018620f320 R08: dffffc0000000000 R09: fffffbfff135d5c8
> kobject: 'loop5' (00000000eac6d22a): kobject_uevent_env
> R10: fffffbfff135d5c8 R11: ffffffff89aeae43 R12: ffff8801bacb38f0
> R13: dffffc0000000000 R14: ffff88018620f2f8 R15: ffff88018620f438
> overlayfs: unrecognized mount option "smackfstransmute=upperdir" or missing
> value
> FS: 00007ff9677ec700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000001b31324000 CR3: 00000001c2773000 CR4: 00000000001406f0
> Call Trace:
> integrity_inode_free+0x12f/0x320 security/integrity/iint.c:150
> security_inode_free+0x19/0x90 security/security.c:453
> __destroy_inode+0x328/0x820 fs/inode.c:238
> destroy_inode+0xda/0x200 fs/inode.c:265
> evict+0x5e0/0x980 fs/inode.c:575
> iput_final fs/inode.c:1547 [inline]
> iput+0x679/0xa90 fs/inode.c:1573
> swap_inode_boot_loader fs/ext4/ioctl.c:188 [inline]
> ext4_ioctl+0x236f/0x4210 fs/ext4/ioctl.c:865
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:501 [inline]
> do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
> ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
> __do_sys_ioctl fs/ioctl.c:709 [inline]
> __se_sys_ioctl fs/ioctl.c:707 [inline]
> __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x457579
> Code: 1d b4 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007ff9677ebc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 0000000000457579
> RDX: 0000000000000000 RSI: 0000000000006611 RDI: 0000000000000003
> RBP: 000000000072c040 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007ff9677ec6d4
> R13: 00000000004bf626 R14: 00000000004cf4c0 R15: 00000000ffffffff
> Modules linked in:
> ---[ end trace 6d41a32e43d56085 ]---
> RIP: 0010:__rb_erase_augmented include/linux/rbtree_augmented.h:168 [inline]
> RIP: 0010:rb_erase+0x306/0x3710 lib/rbtree.c:459
> Code: c7 81 28 01 00 00 f2 f2 f2 f2 c7 81 2c 01 00 00 00 f2 f2 f2 48 89 f9
> 65 48 8b 1c 25 28 00 00 00 48 89 5d d0 31 db 48 c1 e9 03 <42> 80 3c 01 00 0f
> 85 41 1c 00 00 4c 8d 48 10 4c 8b 78 08 48 b9 00
> RSP: 0018:ffff88018620e918 EFLAGS: 00010202
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
> RDX: 1ffff10030c41d2b RSI: ffffffff8b5a08a0 RDI: 0000000000000008
> RBP: ffff88018620f320 R08: dffffc0000000000 R09: fffffbfff135d5c8
> R10: fffffbfff135d5c8 R11: ffffffff89aeae43 R12: ffff8801bacb38f0
> R13: dffffc0000000000 R14: ffff88018620f2f8 R15: ffff88018620f438
> FS: 00007ff9677ec700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000001b31324000 CR3: 00000001c2773000 CR4: 00000000001406f0
>
>
> ---
> 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#bug-status-tracking 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/0000000000009581bf0576c16d3a%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* KASAN: global-out-of-bounds Read in __aa_lookupn_ns
From: syzbot @ 2018-09-26 7:54 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 02214bfc89c7 Merge tag 'media/v4.19-2' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1456f8a1400000
kernel config: https://syzkaller.appspot.com/x/.config?x=22a62640793a83c9
dashboard link: https://syzkaller.appspot.com/bug?extid=71b6643475f707f93fdc
compiler: gcc (GCC) 8.0.1 20180413 (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+71b6643475f707f93fdc@syzkaller.appspotmail.com
sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3038
__sys_setsockopt+0x1ba/0x3c0 net/socket.c:1902
__do_sys_setsockopt net/socket.c:1913 [inline]
__se_sys_setsockopt net/socket.c:1910 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:1910
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
==================================================================
BUG: KASAN: global-out-of-bounds in memcmp+0xe3/0x160 lib/string.c:861
Read of size 1 at addr ffffffff88000008 by task syz-executor0/10914
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457579
Code: 1d b4 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f4c14533c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007f4c14533c90 RCX: 0000000000457579
RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 000000000072bf00 R08: 0000000000000004 R09: 0000000000000000
R10: 0000000020000080 R11: 0000000000000246 R12: 00007f4c145346d4
R13: 00000000004c3ed9 R14: 00000000004d6260 R15: 0000000000000004
CPU: 0 PID: 10914 Comm: syz-executor0 Not tainted 4.19.0-rc5+ #252
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+0x1c4/0x2b4 lib/dump_stack.c:113
print_address_description.cold.8+0x58/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
memcmp+0xe3/0x160 lib/string.c:861
strnstr+0x4b/0x70 lib/string.c:934
__aa_lookupn_ns+0xc1/0x570 security/apparmor/policy_ns.c:209
aa_lookupn_ns+0x88/0x1e0 security/apparmor/policy_ns.c:240
aa_fqlookupn_profile+0x1b9/0x1010 security/apparmor/policy.c:468
fqlookupn_profile+0x80/0xc0 security/apparmor/label.c:1844
aa_label_strn_parse+0xa3a/0x1230 security/apparmor/label.c:1908
aa_label_parse+0x42/0x50 security/apparmor/label.c:1943
aa_change_profile+0x513/0x3510 security/apparmor/domain.c:1362
apparmor_setprocattr+0xa8b/0x1150 security/apparmor/lsm.c:656
security_setprocattr+0x66/0xc0 security/security.c:1298
proc_pid_attr_write+0x301/0x540 fs/proc/base.c:2555
__vfs_write+0x119/0x9f0 fs/read_write.c:485
vfs_write+0x1fc/0x560 fs/read_write.c:549
ksys_write+0x101/0x260 fs/read_write.c:598
__do_sys_write fs/read_write.c:610 [inline]
__se_sys_write fs/read_write.c:607 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:607
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457579
Code: 1d b4 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f5a92ec2c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457579
RDX: 000000000000002c RSI: 00000000200000c0 RDI: 0000000000000004
RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f5a92ec36d4
R13: 00000000004c5454 R14: 00000000004d8c78 R15: 00000000ffffffff
CPU: 1 PID: 10921 Comm: syz-executor3 Not tainted 4.19.0-rc5+ #252
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
The buggy address belongs to the variable:
__start_rodata+0x8/0x1000
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
Memory state around the buggy address:
ffffffff87ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffffff87ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x17 lib/fault-inject.c:149
> ffffffff88000000: 00 fa fa fa fa fa fa fa 00 01 fa fa fa fa fa fa
^
ffffffff88000080: 00 00 00 07 fa fa fa fa 00 04 fa fa fa fa fa fa
ffffffff88000100: 05 fa fa fa fa fa fa fa 00 00 00 00 05 fa fa fa
==================================================================
---
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#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* RE: [PATCH net-next] tls: Fix socket mem accounting error under async encryption
From: Vakul Garg @ 2018-09-26 1:54 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com,
davejwatson@fb.com, doronrk@fb.com
In-Reply-To: <20180925.104416.341573509848387687.davem@davemloft.net>
> -----Original Message-----
> From: David Miller <davem@davemloft.net>
> Sent: Tuesday, September 25, 2018 11:14 PM
> To: Vakul Garg <vakul.garg@nxp.com>
> Cc: netdev@vger.kernel.org; borisp@mellanox.com;
> aviadye@mellanox.com; davejwatson@fb.com; doronrk@fb.com
> Subject: Re: [PATCH net-next] tls: Fix socket mem accounting error under
> async encryption
>
> From: Vakul Garg <vakul.garg@nxp.com>
> Date: Tue, 25 Sep 2018 16:26:17 +0530
>
> > Current async encryption implementation sometimes showed up socket
> > memory accounting error during socket close. This results in kernel
> > warning calltrace. The root cause of the problem is that socket var
> > sk_forward_alloc gets corrupted due to access in sk_mem_charge() and
> > sk_mem_uncharge() being invoked from multiple concurrent contexts in
> > multicore processor. The apis sk_mem_charge() and sk_mem_uncharge()
> > are called from functions alloc_plaintext_sg(), free_sg() etc. It is
> > required that memory accounting apis are called under a socket lock.
> >
> > The plaintext sg data sent for encryption is freed using free_sg() in
> > tls_encryption_done(). It is wrong to call free_sg() from this function.
> > This is because this function may run in irq context. We cannot
> > acquire socket lock in this function.
> >
> > We remove calling of function free_sg() for plaintext data from
> > tls_encryption_done() and defer freeing up of plaintext data to the
> > time when the record is picked up from tx_list and transmitted/freed.
> > When
> > tls_tx_records() gets called, socket is already locked and thus there
> > is no concurrent access problem.
> >
> > Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption")
> > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
>
> Applied.
I don't find this patch and one other ("tls: Fixed a memory leak during socket close")
in linux-net-next. Could you please kindly check? Regards.
^ permalink raw reply
* Re: [PATCH net RFT] bnxt_en: Fix TX timeout during netpoll.
From: Michael Chan @ 2018-09-26 2:14 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Song Liu, Eric Dumazet, David Miller, Netdev
In-Reply-To: <CACKFLik_gNs2MOfKSFARMxqKRJ2UCJ6KgbJ+wSgu6wRvDN3saQ@mail.gmail.com>
On Tue, Sep 25, 2018 at 4:11 PM Michael Chan <michael.chan@broadcom.com> wrote:
>
> On Tue, Sep 25, 2018 at 3:15 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> >
> > It seems bnx2 should have a similar issue ?
> >
>
> Yes, I think so. The MSIX mode in bnx2 is also auto-masking, meaning
> that MSIX will only assert once after it is ARMed. If we return from
> ->poll() when budget of 0 is reached without ARMing, we may not get
> another MSIX.
>
On second thought, I think bnx2 is ok. If netpoll is polling on the
TX packets and reaching budget of 0 and returning, the INT_ACK_CMD
register is untouched. bnx2 uses the status block for events and the
producers/consumers are cumulative. So there is no need to ACK the
status block unless ARMing for interrupts. If there is an IRQ about
to be fired, it won't be affected by the polling done by netpoll.
In the case of bnxt, a completion ring is used for the events. The
polling done by netpoll will cause the completion ring to be ACKed as
entries are processed. ACKing the completion ring without ARMing may
cause future IRQs to be disabled for that ring.
^ permalink raw reply
* Re: [PATCH net RFT] bnxt_en: Fix TX timeout during netpoll.
From: Eric Dumazet @ 2018-09-26 2:25 UTC (permalink / raw)
To: Michael Chan; +Cc: Eric Dumazet, Song Liu, David Miller, netdev
In-Reply-To: <CACKFLimKTzseP34wyZ+SyASG6-2Zn=KF611PY=LO23pJLq4nNg@mail.gmail.com>
On Tue, Sep 25, 2018 at 7:15 PM Michael Chan <michael.chan@broadcom.com> wrote:
>
> On Tue, Sep 25, 2018 at 4:11 PM Michael Chan <michael.chan@broadcom.com> wrote:
> >
> > On Tue, Sep 25, 2018 at 3:15 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > >
> > > It seems bnx2 should have a similar issue ?
> > >
> >
> > Yes, I think so. The MSIX mode in bnx2 is also auto-masking, meaning
> > that MSIX will only assert once after it is ARMed. If we return from
> > ->poll() when budget of 0 is reached without ARMing, we may not get
> > another MSIX.
> >
>
> On second thought, I think bnx2 is ok. If netpoll is polling on the
> TX packets and reaching budget of 0 and returning, the INT_ACK_CMD
> register is untouched. bnx2 uses the status block for events and the
> producers/consumers are cumulative. So there is no need to ACK the
> status block unless ARMing for interrupts. If there is an IRQ about
> to be fired, it won't be affected by the polling done by netpoll.
>
> In the case of bnxt, a completion ring is used for the events. The
> polling done by netpoll will cause the completion ring to be ACKed as
> entries are processed. ACKing the completion ring without ARMing may
> cause future IRQs to be disabled for that ring.
About bnxt : Are you sure it is all about IRQ problems ?
What if the whole ring buffer is is filled, then all entries
are processed from netpoll.
If cp_raw_cons becomes too high without the NIC knowing its (updated)
value, maybe no IRQ can be generated anymore because
of some wrapping issue (based on ring size)
I guess that in order to test this, we would need something bursting
16000 messages while holding napi->poll_owner.
The (single) IRQ would set/grab the SCHED bit but the cpu responsible
to service this (soft)irq would spin for the whole test,
and no more IRQ should be fired really.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 03/10] bpf: introduce per-cpu cgroup local storage
From: Roman Gushchin @ 2018-09-26 8:42 UTC (permalink / raw)
To: Song Liu
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Kernel Team,
Daniel Borkmann, Alexei Starovoitov
In-Reply-To: <27B81458-17C5-4840-9679-D1F5FBF6E805@fb.com>
On Tue, Sep 25, 2018 at 11:54:33AM -0700, Song Liu wrote:
>
>
> > On Sep 25, 2018, at 8:21 AM, Roman Gushchin <guro@fb.com> wrote:
> >
> > This commit introduced per-cpu cgroup local storage.
> >
> > Per-cpu cgroup local storage is very similar to simple cgroup storage
> > (let's call it shared), except all the data is per-cpu.
> >
> > The main goal of per-cpu variant is to implement super fast
> > counters (e.g. packet counters), which don't require neither
> > lookups, neither atomic operations.
> >
> > From userspace's point of view, accessing a per-cpu cgroup storage
> > is similar to other per-cpu map types (e.g. per-cpu hashmaps and
> > arrays).
> >
> > Writing to a per-cpu cgroup storage is not atomic, but is performed
> > by copying longs, so some minimal atomicity is here, exactly
> > as with other per-cpu maps.
> >
> > Signed-off-by: Roman Gushchin <guro@fb.com>
> > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > Cc: Alexei Starovoitov <ast@kernel.org>
> > ---
> > include/linux/bpf-cgroup.h | 20 ++++-
> > include/linux/bpf.h | 1 +
> > include/linux/bpf_types.h | 1 +
> > include/uapi/linux/bpf.h | 1 +
> > kernel/bpf/helpers.c | 8 +-
> > kernel/bpf/local_storage.c | 148 ++++++++++++++++++++++++++++++++-----
> > kernel/bpf/syscall.c | 11 ++-
> > kernel/bpf/verifier.c | 15 +++-
> > 8 files changed, 177 insertions(+), 28 deletions(-)
> >
> > diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
> > index 7e0c9a1d48b7..9bd907657f9b 100644
> > --- a/include/linux/bpf-cgroup.h
> > +++ b/include/linux/bpf-cgroup.h
> > @@ -37,7 +37,10 @@ struct bpf_storage_buffer {
> > };
> >
> > struct bpf_cgroup_storage {
> > - struct bpf_storage_buffer *buf;
> > + union {
> > + struct bpf_storage_buffer *buf;
> > + char __percpu *percpu_buf;
>
> "char *" here looks weird. Did you mean to use "void *"?
Fair enough. It's probably a leftover from (previously used) char[0].
>
> > + };
> > struct bpf_cgroup_storage_map *map;
> > struct bpf_cgroup_storage_key key;
> > struct list_head list;
> > @@ -109,6 +112,9 @@ int __cgroup_bpf_check_dev_permission(short dev_type, u32 major, u32 minor,
> > static inline enum bpf_cgroup_storage_type cgroup_storage_type(
> > struct bpf_map *map)
> > {
> > + if (map->map_type == BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE)
> > + return BPF_CGROUP_STORAGE_PERCPU;
> > +
> > return BPF_CGROUP_STORAGE_SHARED;
> > }
> >
> > @@ -131,6 +137,10 @@ void bpf_cgroup_storage_unlink(struct bpf_cgroup_storage *storage);
> > int bpf_cgroup_storage_assign(struct bpf_prog *prog, struct bpf_map *map);
> > void bpf_cgroup_storage_release(struct bpf_prog *prog, struct bpf_map *map);
> >
> > +int bpf_percpu_cgroup_storage_copy(struct bpf_map *map, void *key, void *value);
> > +int bpf_percpu_cgroup_storage_update(struct bpf_map *map, void *key,
> > + void *value, u64 flags);
> > +
> > /* Wrappers for __cgroup_bpf_run_filter_skb() guarded by cgroup_bpf_enabled. */
> > #define BPF_CGROUP_RUN_PROG_INET_INGRESS(sk, skb) \
> > ({ \
> > @@ -285,6 +295,14 @@ static inline struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(
> > struct bpf_prog *prog, enum bpf_cgroup_storage_type stype) { return 0; }
> > static inline void bpf_cgroup_storage_free(
> > struct bpf_cgroup_storage *storage) {}
> > +static inline int bpf_percpu_cgroup_storage_copy(struct bpf_map *map, void *key,
> > + void *value) {
> > + return 0;
> > +}
> > +static inline int bpf_percpu_cgroup_storage_update(struct bpf_map *map,
> > + void *key, void *value, u64 flags) {
> > + return 0;
> > +}
> >
> > #define cgroup_bpf_enabled (0)
> > #define BPF_CGROUP_PRE_CONNECT_ENABLED(sk) (0)
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index b457fbe7b70b..018299a595c8 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -274,6 +274,7 @@ struct bpf_prog_offload {
> >
> > enum bpf_cgroup_storage_type {
> > BPF_CGROUP_STORAGE_SHARED,
> > + BPF_CGROUP_STORAGE_PERCPU,
> > __BPF_CGROUP_STORAGE_MAX
> > };
> >
> > diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
> > index c9bd6fb765b0..5432f4c9f50e 100644
> > --- a/include/linux/bpf_types.h
> > +++ b/include/linux/bpf_types.h
> > @@ -43,6 +43,7 @@ BPF_MAP_TYPE(BPF_MAP_TYPE_CGROUP_ARRAY, cgroup_array_map_ops)
> > #endif
> > #ifdef CONFIG_CGROUP_BPF
> > BPF_MAP_TYPE(BPF_MAP_TYPE_CGROUP_STORAGE, cgroup_storage_map_ops)
> > +BPF_MAP_TYPE(BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE, cgroup_storage_map_ops)
> > #endif
> > BPF_MAP_TYPE(BPF_MAP_TYPE_HASH, htab_map_ops)
> > BPF_MAP_TYPE(BPF_MAP_TYPE_PERCPU_HASH, htab_percpu_map_ops)
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index aa5ccd2385ed..e2070d819e04 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -127,6 +127,7 @@ enum bpf_map_type {
> > BPF_MAP_TYPE_SOCKHASH,
> > BPF_MAP_TYPE_CGROUP_STORAGE,
> > BPF_MAP_TYPE_REUSEPORT_SOCKARRAY,
> > + BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE,
> > };
> >
> > enum bpf_prog_type {
> > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> > index e42f8789b7ea..1f21ef1c4ad3 100644
> > --- a/kernel/bpf/helpers.c
> > +++ b/kernel/bpf/helpers.c
> > @@ -206,10 +206,16 @@ BPF_CALL_2(bpf_get_local_storage, struct bpf_map *, map, u64, flags)
> > */
> > enum bpf_cgroup_storage_type stype = cgroup_storage_type(map);
> > struct bpf_cgroup_storage *storage;
> > + void *ptr = NULL;
>
> Not necessary to initialize to NULL.
Fixed.
>
> >
> > storage = this_cpu_read(bpf_cgroup_storage[stype]);
> >
> > - return (unsigned long)&READ_ONCE(storage->buf)->data[0];
> > + if (stype == BPF_CGROUP_STORAGE_SHARED)
> > + ptr = &READ_ONCE(storage->buf)->data[0];
> > + else
> > + ptr = this_cpu_ptr(storage->percpu_buf);
> > +
> > + return (unsigned long)ptr;
> > }
> >
> > const struct bpf_func_proto bpf_get_local_storage_proto = {
> > diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
> > index 6742292fb39e..d991355b5b46 100644
> > --- a/kernel/bpf/local_storage.c
> > +++ b/kernel/bpf/local_storage.c
> > @@ -152,6 +152,71 @@ static int cgroup_storage_update_elem(struct bpf_map *map, void *_key,
> > return 0;
> > }
> >
> > +int bpf_percpu_cgroup_storage_copy(struct bpf_map *_map, void *_key,
> > + void *value)
> > +{
> > + struct bpf_cgroup_storage_map *map = map_to_storage(_map);
> > + struct bpf_cgroup_storage_key *key = _key;
> > + struct bpf_cgroup_storage *storage;
> > + int cpu, off = 0;
> > + u32 size;
> > +
> > + rcu_read_lock();
> > + storage = cgroup_storage_lookup(map, key, false);
> > + if (!storage) {
> > + rcu_read_unlock();
> > + return -ENOENT;
> > + }
> > +
> > + /* per_cpu areas are zero-filled and bpf programs can only
> > + * access 'value_size' of them, so copying rounded areas
> > + * will not leak any kernel data
> > + */
> > + size = round_up(_map->value_size, 8);
> > + for_each_possible_cpu(cpu) {
> > + bpf_long_memcpy(value + off,
> > + per_cpu_ptr(storage->percpu_buf, cpu), size);
> > + off += size;
> > + }
> > + rcu_read_unlock();
> > + return 0;
> > +}
> > +
> > +int bpf_percpu_cgroup_storage_update(struct bpf_map *_map, void *_key,
> > + void *value, u64 map_flags)
> > +{
> > + struct bpf_cgroup_storage_map *map = map_to_storage(_map);
> > + struct bpf_cgroup_storage_key *key = _key;
> > + struct bpf_cgroup_storage *storage;
> > + int cpu, off = 0;
> > + u32 size;
> > +
> > + if (unlikely(map_flags & BPF_EXIST))
> > + return -EINVAL;
> > +
> > + rcu_read_lock();
> > + storage = cgroup_storage_lookup(map, key, false);
> > + if (!storage) {
> > + rcu_read_unlock();
> > + return -ENOENT;
> > + }
> > +
> > + /* the user space will provide round_up(value_size, 8) bytes that
> > + * will be copied into per-cpu area. bpf programs can only access
> > + * value_size of it. During lookup the same extra bytes will be
> > + * returned or zeros which were zero-filled by percpu_alloc,
> > + * so no kernel data leaks possible
> > + */
> > + size = round_up(_map->value_size, 8);
> > + for_each_possible_cpu(cpu) {
> > + bpf_long_memcpy(per_cpu_ptr(storage->percpu_buf, cpu),
> > + value + off, size);
> > + off += size;
> > + }
> > + rcu_read_unlock();
> > + return 0;
> > +}
> > +
> > static int cgroup_storage_get_next_key(struct bpf_map *_map, void *_key,
> > void *_next_key)
> > {
> > @@ -292,55 +357,98 @@ struct bpf_cgroup_storage *bpf_cgroup_storage_alloc(struct bpf_prog *prog,
> > {
> > struct bpf_cgroup_storage *storage;
> > struct bpf_map *map;
> > + gfp_t flags;
> > + size_t size;
> > u32 pages;
> >
> > map = prog->aux->cgroup_storage[stype];
> > if (!map)
> > return NULL;
> >
> > - pages = round_up(sizeof(struct bpf_cgroup_storage) +
> > - sizeof(struct bpf_storage_buffer) +
> > - map->value_size, PAGE_SIZE) >> PAGE_SHIFT;
> > + if (stype == BPF_CGROUP_STORAGE_SHARED) {
> > + size = sizeof(struct bpf_storage_buffer) + map->value_size;
> > + pages = round_up(sizeof(struct bpf_cgroup_storage) + size,
> > + PAGE_SIZE) >> PAGE_SHIFT;
> > + } else {
> > + size = map->value_size;
> > + pages = round_up(round_up(size, 8) * num_possible_cpus(),
> > + PAGE_SIZE) >> PAGE_SHIFT;
> > + }
> > +
> > if (bpf_map_charge_memlock(map, pages))
> > return ERR_PTR(-EPERM);
> >
> > storage = kmalloc_node(sizeof(struct bpf_cgroup_storage),
> > __GFP_ZERO | GFP_USER, map->numa_node);
> > - if (!storage) {
> > - bpf_map_uncharge_memlock(map, pages);
> > - return ERR_PTR(-ENOMEM);
> > - }
> > + if (!storage)
> > + goto enomem;
> >
> > - storage->buf = kmalloc_node(sizeof(struct bpf_storage_buffer) +
> > - map->value_size, __GFP_ZERO | GFP_USER,
> > - map->numa_node);
> > - if (!storage->buf) {
> > - bpf_map_uncharge_memlock(map, pages);
> > - kfree(storage);
> > - return ERR_PTR(-ENOMEM);
> > + flags = __GFP_ZERO | GFP_USER;
> > +
> > + if (stype == BPF_CGROUP_STORAGE_SHARED) {
> > + storage->buf = kmalloc_node(size, flags, map->numa_node);
> > + if (!storage->buf)
> > + goto enomem;
> > + } else {
> > + storage->percpu_buf = __alloc_percpu_gfp(size, 8, flags);
> > + if (!storage->percpu_buf)
> > + goto enomem;
> > }
> >
> > storage->map = (struct bpf_cgroup_storage_map *)map;
> >
> > return storage;
> > +
> > +enomem:
> > + bpf_map_uncharge_memlock(map, pages);
> > + kfree(storage);
> > + return ERR_PTR(-ENOMEM);
> > +}
> > +
> > +static void free_cgroup_storage_rcu(struct rcu_head *rcu)
>
> Maybe rename as free_shared_cgroup_storage_rcu()?
Yeah, might be more clear.
Thank you for the review!
Will send v3 with these changes and your acks soon.
Thanks!
^ permalink raw reply
* [PATCH net] vxlan: fill ttl inherit info
From: Hangbin Liu @ 2018-09-26 2:35 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Hangbin Liu
When add vxlan ttl inherit support, I forgot to fill it when dump
vlxan info. Fix it now.
Fixes: 72f6d71e491e6 ("vxlan: add ttl inherit support")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
drivers/net/vxlan.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index ababba3..2b8da2b 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -3539,6 +3539,7 @@ static size_t vxlan_get_size(const struct net_device *dev)
nla_total_size(sizeof(__u32)) + /* IFLA_VXLAN_LINK */
nla_total_size(sizeof(struct in6_addr)) + /* IFLA_VXLAN_LOCAL{6} */
nla_total_size(sizeof(__u8)) + /* IFLA_VXLAN_TTL */
+ nla_total_size(sizeof(__u8)) + /* IFLA_VXLAN_TTL_INHERIT */
nla_total_size(sizeof(__u8)) + /* IFLA_VXLAN_TOS */
nla_total_size(sizeof(__be32)) + /* IFLA_VXLAN_LABEL */
nla_total_size(sizeof(__u8)) + /* IFLA_VXLAN_LEARNING */
@@ -3603,6 +3604,8 @@ static int vxlan_fill_info(struct sk_buff *skb, const struct net_device *dev)
}
if (nla_put_u8(skb, IFLA_VXLAN_TTL, vxlan->cfg.ttl) ||
+ nla_put_u8(skb, IFLA_VXLAN_TTL_INHERIT,
+ !!(vxlan->cfg.flags & VXLAN_F_TTL_INHERIT)) ||
nla_put_u8(skb, IFLA_VXLAN_TOS, vxlan->cfg.tos) ||
nla_put_be32(skb, IFLA_VXLAN_LABEL, vxlan->cfg.label) ||
nla_put_u8(skb, IFLA_VXLAN_LEARNING,
--
2.5.5
^ permalink raw reply related
* [PATCH] net: qed: list usage cleanup
From: zhong jiang @ 2018-09-26 8:53 UTC (permalink / raw)
To: davem; +Cc: Ariel.Elior, everest-linux-l2, netdev, linux-kernel
Trival cleanup, list_move_tail will implement the same function that
list_del() + list_add_tail() will do. hence just replace them.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 9 ++++-----
drivers/net/ethernet/qlogic/qed/qed_ooo.c | 10 ++++------
drivers/net/ethernet/qlogic/qed/qed_spq.c | 3 +--
3 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
index 17f3dfa..f99797a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
@@ -935,9 +935,8 @@ int qed_iwarp_destroy_qp(struct qed_hwfn *p_hwfn, struct qed_rdma_qp *qp)
}
spin_lock_bh(&p_hwfn->p_rdma_info->iwarp.iw_lock);
- list_del(&ep->list_entry);
- list_add_tail(&ep->list_entry,
- &p_hwfn->p_rdma_info->iwarp.ep_free_list);
+ list_move_tail(&ep->list_entry,
+ &p_hwfn->p_rdma_info->iwarp.ep_free_list);
spin_unlock_bh(&p_hwfn->p_rdma_info->iwarp.iw_lock);
}
@@ -2270,8 +2269,8 @@ static void qed_iwarp_process_pending_pkts(struct qed_hwfn *p_hwfn)
if (rc == -EBUSY)
break;
- list_del(&mpa_buf->list_entry);
- list_add_tail(&mpa_buf->list_entry, &iwarp_info->mpa_buf_list);
+ list_move_tail(&mpa_buf->list_entry,
+ &iwarp_info->mpa_buf_list);
if (rc) { /* different error, don't continue */
DP_NOTICE(p_hwfn, "process pkts failed rc=%d\n", rc);
diff --git a/drivers/net/ethernet/qlogic/qed/qed_ooo.c b/drivers/net/ethernet/qlogic/qed/qed_ooo.c
index 6172354..63931df 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_ooo.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_ooo.c
@@ -211,9 +211,8 @@ void qed_ooo_release_connection_isles(struct qed_hwfn *p_hwfn,
if (!p_buffer)
break;
- list_del(&p_buffer->list_entry);
- list_add_tail(&p_buffer->list_entry,
- &p_ooo_info->free_buffers_list);
+ list_move_tail(&p_buffer->list_entry,
+ &p_ooo_info->free_buffers_list);
}
list_add_tail(&p_isle->list_entry,
&p_ooo_info->free_isles_list);
@@ -247,9 +246,8 @@ void qed_ooo_release_all_isles(struct qed_hwfn *p_hwfn,
if (!p_buffer)
break;
- list_del(&p_buffer->list_entry);
- list_add_tail(&p_buffer->list_entry,
- &p_ooo_info->free_buffers_list);
+ list_move_tail(&p_buffer->list_entry,
+ &p_ooo_info->free_buffers_list);
}
list_add_tail(&p_isle->list_entry,
&p_ooo_info->free_isles_list);
diff --git a/drivers/net/ethernet/qlogic/qed/qed_spq.c b/drivers/net/ethernet/qlogic/qed/qed_spq.c
index 1673fc9..c4a6274 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_spq.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_spq.c
@@ -730,8 +730,7 @@ static int qed_spq_post_list(struct qed_hwfn *p_hwfn,
!list_empty(head)) {
struct qed_spq_entry *p_ent =
list_first_entry(head, struct qed_spq_entry, list);
- list_del(&p_ent->list);
- list_add_tail(&p_ent->list, &p_spq->completion_pending);
+ list_move_tail(&p_ent->list, &p_spq->completion_pending);
p_spq->comp_sent_count++;
rc = qed_spq_hw_post(p_hwfn, p_spq, p_ent);
--
1.7.12.4
^ permalink raw reply related
* [PATCH] net: liquidio: list usage cleanup
From: zhong jiang @ 2018-09-26 8:56 UTC (permalink / raw)
To: davem; +Cc: derek.chickles, satananda.burla, felix.manlunas, netdev,
linux-kernel
Trival cleanup, list_move_tail will implement the same function that
list_del() + list_add_tail() will do. hence just replace them.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/ethernet/cavium/liquidio/octeon_device.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.c b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
index 0f0275c..ce8c3f8 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
@@ -1044,8 +1044,7 @@ void octeon_delete_dispatch_list(struct octeon_device *oct)
dispatch = &oct->dispatch.dlist[i].list;
while (dispatch->next != dispatch) {
temp = dispatch->next;
- list_del(temp);
- list_add_tail(temp, &freelist);
+ list_move_tail(temp, &freelist);
}
oct->dispatch.dlist[i].opcode = 0;
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH v2 net-next] tcp: expose sk_state in tcp_retransmit_skb tracepoint
From: Eric Dumazet @ 2018-09-26 2:47 UTC (permalink / raw)
To: Yafang Shao, edumazet, davem; +Cc: netdev
In-Reply-To: <1537793849-32396-1-git-send-email-laoar.shao@gmail.com>
On 09/24/2018 05:57 AM, Yafang Shao wrote:
> After sk_state exposed, we can get in which state this retransmission
> occurs. That could give us more detail for dignostic.
> For example, if this retransmission occurs in SYN_SENT state, it may
> also indicates that the syn packet may be dropped on the remote peer due
> to syn backlog queue full and then we could check the remote peer.
>
> BTW,SYNACK retransmission is traced in tcp_retransmit_synack tracepoint.
>
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Ard Biesheuvel @ 2018-09-26 8:59 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Linux Kernel Mailing List, <netdev@vger.kernel.org>,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, David S. Miller,
Greg Kroah-Hartman, Samuel Neves, Andy Lutomirski,
Jean-Philippe Aumasson, Russell King, linux-arm-kernel
In-Reply-To: <20180925145622.29959-8-Jason@zx2c4.com>
On Tue, 25 Sep 2018 at 17:00, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> These wire Andy Polyakov's implementations up to the kernel for ARMv7,8
> NEON, and introduce Eric Biggers' ultra-fast scalar implementation for
> CPUs without NEON or for CPUs with slow NEON (Cortex-A5,7).
>
> This commit does the following:
> - Adds the glue code for the assembly implementations.
> - Renames the ARMv8 code into place, since it can at this point be
> used wholesale.
> - Merges Andy Polyakov's ARMv7 NEON code with Eric Biggers' <=ARMv7
> scalar code.
>
> Commit note: Eric Biggers' scalar code is brand new, and quite possibly
> prematurely added to this commit, and so it may require a bit of revision.
>
> This commit delivers approximately the same or much better performance than
> the existing crypto API's code and has been measured to do as such on:
>
> - ARM1176JZF-S [ARMv6]
> - Cortex-A7 [ARMv7]
> - Cortex-A8 [ARMv7]
> - Cortex-A9 [ARMv7]
> - Cortex-A17 [ARMv7]
> - Cortex-A53 [ARMv8]
> - Cortex-A55 [ARMv8]
> - Cortex-A73 [ARMv8]
> - Cortex-A75 [ARMv8]
>
> Interestingly, Andy Polyakov's scalar code is slower than Eric Biggers',
> but is also significantly shorter. This has the advantage that it does
> not evict other code from L1 cache -- particularly on ARM11 chips -- and
> so in certain circumstances it can actually be faster. However, it wasn't
> found that this had an affect on any code existing in the kernel today.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Co-authored-by: Eric Biggers <ebiggers@google.com>
> Cc: Samuel Neves <sneves@dei.uc.pt>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> lib/zinc/Makefile | 2 +
> lib/zinc/chacha20/chacha20-arm-glue.h | 88 +++
> ...acha20-arm-cryptogams.S => chacha20-arm.S} | 502 ++++++++++++++++--
> ...20-arm64-cryptogams.S => chacha20-arm64.S} | 0
> lib/zinc/chacha20/chacha20.c | 2 +
> 5 files changed, 556 insertions(+), 38 deletions(-)
> create mode 100644 lib/zinc/chacha20/chacha20-arm-glue.h
> rename lib/zinc/chacha20/{chacha20-arm-cryptogams.S => chacha20-arm.S} (71%)
> rename lib/zinc/chacha20/{chacha20-arm64-cryptogams.S => chacha20-arm64.S} (100%)
>
> diff --git a/lib/zinc/Makefile b/lib/zinc/Makefile
> index 223a0816c918..e47f64e12bbd 100644
> --- a/lib/zinc/Makefile
> +++ b/lib/zinc/Makefile
> @@ -4,4 +4,6 @@ ccflags-$(CONFIG_ZINC_DEBUG) += -DDEBUG
>
> zinc_chacha20-y := chacha20/chacha20.o
> zinc_chacha20-$(CONFIG_ZINC_ARCH_X86_64) += chacha20/chacha20-x86_64.o
> +zinc_chacha20-$(CONFIG_ZINC_ARCH_ARM) += chacha20/chacha20-arm.o
> +zinc_chacha20-$(CONFIG_ZINC_ARCH_ARM64) += chacha20/chacha20-arm64.o
> obj-$(CONFIG_ZINC_CHACHA20) += zinc_chacha20.o
> diff --git a/lib/zinc/chacha20/chacha20-arm-glue.h b/lib/zinc/chacha20/chacha20-arm-glue.h
> new file mode 100644
> index 000000000000..86cce851ed02
> --- /dev/null
> +++ b/lib/zinc/chacha20/chacha20-arm-glue.h
> @@ -0,0 +1,88 @@
> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> +/*
> + * Copyright (C) 2015-2018 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
> + */
> +
> +#include <asm/hwcap.h>
> +#include <asm/neon.h>
> +#if defined(CONFIG_ARM)
> +#include <asm/system_info.h>
> +#include <asm/cputype.h>
> +#endif
> +
> +asmlinkage void chacha20_arm(u8 *out, const u8 *in, const size_t len,
> + const u32 key[8], const u32 counter[4]);
> +#if defined(CONFIG_ARM)
> +asmlinkage void hchacha20_arm(const u32 state[16], u32 out[8]);
> +#endif
> +#if defined(CONFIG_KERNEL_MODE_NEON)
> +asmlinkage void chacha20_neon(u8 *out, const u8 *in, const size_t len,
> + const u32 key[8], const u32 counter[4]);
> +#endif
> +
> +static bool chacha20_use_neon __ro_after_init;
> +
> +static void __init chacha20_fpu_init(void)
> +{
> +#if defined(CONFIG_ARM64)
> + chacha20_use_neon = elf_hwcap & HWCAP_ASIMD;
> +#elif defined(CONFIG_ARM)
> + switch (read_cpuid_part()) {
> + case ARM_CPU_PART_CORTEX_A7:
> + case ARM_CPU_PART_CORTEX_A5:
> + /* The Cortex-A7 and Cortex-A5 do not perform well with the NEON
> + * implementation but do incredibly with the scalar one and use
> + * less power.
> + */
> + break;
> + default:
> + chacha20_use_neon = elf_hwcap & HWCAP_NEON;
> + }
> +#endif
> +}
> +
> +static inline bool chacha20_arch(struct chacha20_ctx *state, u8 *dst,
> + const u8 *src, size_t len,
> + simd_context_t *simd_context)
> +{
> +#if defined(CONFIG_KERNEL_MODE_NEON)
> + if (chacha20_use_neon && len >= CHACHA20_BLOCK_SIZE * 3 &&
> + simd_use(simd_context))
> + chacha20_neon(dst, src, len, state->key, state->counter);
> + else
> +#endif
Better to use IS_ENABLED() here:
> + if (IS_ENABLED(CONFIG_KERNEL_MODE_NEON)) &&
> + chacha20_use_neon && len >= CHACHA20_BLOCK_SIZE * 3 &&
> + simd_use(simd_context))
Also, this still has unbounded worst case scheduling latency, given
that the outer library function passes its entire input straight into
the NEON routine.
> + chacha20_arm(dst, src, len, state->key, state->counter);
> +
> + state->counter[0] += (len + 63) / 64;
> + return true;
> +}
> +
> +static inline bool hchacha20_arch(u32 derived_key[CHACHA20_KEY_WORDS],
> + const u8 nonce[HCHACHA20_NONCE_SIZE],
> + const u8 key[HCHACHA20_KEY_SIZE],
> + simd_context_t *simd_context)
> +{
> +#if defined(CONFIG_ARM)
> + u32 x[] = { CHACHA20_CONSTANT_EXPA,
> + CHACHA20_CONSTANT_ND_3,
> + CHACHA20_CONSTANT_2_BY,
> + CHACHA20_CONSTANT_TE_K,
> + get_unaligned_le32(key + 0),
> + get_unaligned_le32(key + 4),
> + get_unaligned_le32(key + 8),
> + get_unaligned_le32(key + 12),
> + get_unaligned_le32(key + 16),
> + get_unaligned_le32(key + 20),
> + get_unaligned_le32(key + 24),
> + get_unaligned_le32(key + 28),
> + get_unaligned_le32(nonce + 0),
> + get_unaligned_le32(nonce + 4),
> + get_unaligned_le32(nonce + 8),
> + get_unaligned_le32(nonce + 12)
> + };
> + hchacha20_arm(x, derived_key);
> + return true;
> +#else
> + return false;
> +#endif
> +}
> diff --git a/lib/zinc/chacha20/chacha20-arm-cryptogams.S b/lib/zinc/chacha20/chacha20-arm.S
> similarity index 71%
> rename from lib/zinc/chacha20/chacha20-arm-cryptogams.S
> rename to lib/zinc/chacha20/chacha20-arm.S
> index 770bab469171..5abedafcf129 100644
> --- a/lib/zinc/chacha20/chacha20-arm-cryptogams.S
> +++ b/lib/zinc/chacha20/chacha20-arm.S
> @@ -1,13 +1,475 @@
> /* SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause */
> /*
> + * Copyright (C) 2018 Google, Inc.
> * Copyright (C) 2015-2018 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
> * Copyright (C) 2006-2017 CRYPTOGAMS by <appro@openssl.org>. All Rights Reserved.
> - *
> - * This is based in part on Andy Polyakov's implementation from CRYPTOGAMS.
> */
>
> #include <linux/linkage.h>
>
> +/*
> + * The following scalar routine was written by Eric Biggers.
> + *
> + * Design notes:
> + *
> + * 16 registers would be needed to hold the state matrix, but only 14 are
> + * available because 'sp' and 'pc' cannot be used. So we spill the elements
> + * (x8, x9) to the stack and swap them out with (x10, x11). This adds one
> + * 'ldrd' and one 'strd' instruction per round.
> + *
> + * All rotates are performed using the implicit rotate operand accepted by the
> + * 'add' and 'eor' instructions. This is faster than using explicit rotate
> + * instructions. To make this work, we allow the values in the second and last
> + * rows of the ChaCha state matrix (rows 'b' and 'd') to temporarily have the
> + * wrong rotation amount. The rotation amount is then fixed up just in time
> + * when the values are used. 'brot' is the number of bits the values in row 'b'
> + * need to be rotated right to arrive at the correct values, and 'drot'
> + * similarly for row 'd'. (brot, drot) start out as (0, 0) but we make it such
> + * that they end up as (25, 24) after every round.
> + */
> +
> + // ChaCha state registers
> + X0 .req r0
> + X1 .req r1
> + X2 .req r2
> + X3 .req r3
> + X4 .req r4
> + X5 .req r5
> + X6 .req r6
> + X7 .req r7
> + X8_X10 .req r8 // shared by x8 and x10
> + X9_X11 .req r9 // shared by x9 and x11
> + X12 .req r10
> + X13 .req r11
> + X14 .req r12
> + X15 .req r14
> +
> +.Lexpand_32byte_k:
> + // "expand 32-byte k"
> + .word 0x61707865, 0x3320646e, 0x79622d32, 0x6b206574
> +
> +#ifdef __thumb2__
> +# define adrl adr
> +#endif
> +
> +.macro __rev out, in, t0, t1, t2
> +.if __LINUX_ARM_ARCH__ >= 6
> + rev \out, \in
> +.else
> + lsl \t0, \in, #24
> + and \t1, \in, #0xff00
> + and \t2, \in, #0xff0000
> + orr \out, \t0, \in, lsr #24
> + orr \out, \out, \t1, lsl #8
> + orr \out, \out, \t2, lsr #8
> +.endif
> +.endm
> +
> +.macro _le32_bswap x, t0, t1, t2
> +#ifdef __ARMEB__
> + __rev \x, \x, \t0, \t1, \t2
> +#endif
> +.endm
> +
> +.macro _le32_bswap_4x a, b, c, d, t0, t1, t2
> + _le32_bswap \a, \t0, \t1, \t2
> + _le32_bswap \b, \t0, \t1, \t2
> + _le32_bswap \c, \t0, \t1, \t2
> + _le32_bswap \d, \t0, \t1, \t2
> +.endm
> +
> +.macro __ldrd a, b, src, offset
> +#if __LINUX_ARM_ARCH__ >= 6
> + ldrd \a, \b, [\src, #\offset]
> +#else
> + ldr \a, [\src, #\offset]
> + ldr \b, [\src, #\offset + 4]
> +#endif
> +.endm
> +
> +.macro __strd a, b, dst, offset
> +#if __LINUX_ARM_ARCH__ >= 6
> + strd \a, \b, [\dst, #\offset]
> +#else
> + str \a, [\dst, #\offset]
> + str \b, [\dst, #\offset + 4]
> +#endif
> +.endm
> +
> +.macro _halfround a1, b1, c1, d1, a2, b2, c2, d2
> +
> + // a += b; d ^= a; d = rol(d, 16);
> + add \a1, \a1, \b1, ror #brot
> + add \a2, \a2, \b2, ror #brot
> + eor \d1, \a1, \d1, ror #drot
> + eor \d2, \a2, \d2, ror #drot
> + // drot == 32 - 16 == 16
> +
> + // c += d; b ^= c; b = rol(b, 12);
> + add \c1, \c1, \d1, ror #16
> + add \c2, \c2, \d2, ror #16
> + eor \b1, \c1, \b1, ror #brot
> + eor \b2, \c2, \b2, ror #brot
> + // brot == 32 - 12 == 20
> +
> + // a += b; d ^= a; d = rol(d, 8);
> + add \a1, \a1, \b1, ror #20
> + add \a2, \a2, \b2, ror #20
> + eor \d1, \a1, \d1, ror #16
> + eor \d2, \a2, \d2, ror #16
> + // drot == 32 - 8 == 24
> +
> + // c += d; b ^= c; b = rol(b, 7);
> + add \c1, \c1, \d1, ror #24
> + add \c2, \c2, \d2, ror #24
> + eor \b1, \c1, \b1, ror #20
> + eor \b2, \c2, \b2, ror #20
> + // brot == 32 - 7 == 25
> +.endm
> +
> +.macro _doubleround
> +
> + // column round
> +
> + // quarterrounds: (x0, x4, x8, x12) and (x1, x5, x9, x13)
> + _halfround X0, X4, X8_X10, X12, X1, X5, X9_X11, X13
> +
> + // save (x8, x9); restore (x10, x11)
> + __strd X8_X10, X9_X11, sp, 0
> + __ldrd X8_X10, X9_X11, sp, 8
> +
> + // quarterrounds: (x2, x6, x10, x14) and (x3, x7, x11, x15)
> + _halfround X2, X6, X8_X10, X14, X3, X7, X9_X11, X15
> +
> + .set brot, 25
> + .set drot, 24
> +
> + // diagonal round
> +
> + // quarterrounds: (x0, x5, x10, x15) and (x1, x6, x11, x12)
> + _halfround X0, X5, X8_X10, X15, X1, X6, X9_X11, X12
> +
> + // save (x10, x11); restore (x8, x9)
> + __strd X8_X10, X9_X11, sp, 8
> + __ldrd X8_X10, X9_X11, sp, 0
> +
> + // quarterrounds: (x2, x7, x8, x13) and (x3, x4, x9, x14)
> + _halfround X2, X7, X8_X10, X13, X3, X4, X9_X11, X14
> +.endm
> +
> +.macro _chacha_permute nrounds
> + .set brot, 0
> + .set drot, 0
> + .rept \nrounds / 2
> + _doubleround
> + .endr
> +.endm
> +
> +.macro _chacha nrounds
> +
> +.Lnext_block\@:
> + // Stack: unused0-unused1 x10-x11 x0-x15 OUT IN LEN
> + // Registers contain x0-x9,x12-x15.
> +
> + // Do the core ChaCha permutation to update x0-x15.
> + _chacha_permute \nrounds
> +
> + add sp, #8
> + // Stack: x10-x11 orig_x0-orig_x15 OUT IN LEN
> + // Registers contain x0-x9,x12-x15.
> + // x4-x7 are rotated by 'brot'; x12-x15 are rotated by 'drot'.
> +
> + // Free up some registers (r8-r12,r14) by pushing (x8-x9,x12-x15).
> + push {X8_X10, X9_X11, X12, X13, X14, X15}
> +
> + // Load (OUT, IN, LEN).
> + ldr r14, [sp, #96]
> + ldr r12, [sp, #100]
> + ldr r11, [sp, #104]
> +
> + orr r10, r14, r12
> +
> + // Use slow path if fewer than 64 bytes remain.
> + cmp r11, #64
> + blt .Lxor_slowpath\@
> +
> + // Use slow path if IN and/or OUT isn't 4-byte aligned. Needed even on
> + // ARMv6+, since ldmia and stmia (used below) still require alignment.
> + tst r10, #3
> + bne .Lxor_slowpath\@
> +
> + // Fast path: XOR 64 bytes of aligned data.
> +
> + // Stack: x8-x9 x12-x15 x10-x11 orig_x0-orig_x15 OUT IN LEN
> + // Registers: r0-r7 are x0-x7; r8-r11 are free; r12 is IN; r14 is OUT.
> + // x4-x7 are rotated by 'brot'; x12-x15 are rotated by 'drot'.
> +
> + // x0-x3
> + __ldrd r8, r9, sp, 32
> + __ldrd r10, r11, sp, 40
> + add X0, X0, r8
> + add X1, X1, r9
> + add X2, X2, r10
> + add X3, X3, r11
> + _le32_bswap_4x X0, X1, X2, X3, r8, r9, r10
> + ldmia r12!, {r8-r11}
> + eor X0, X0, r8
> + eor X1, X1, r9
> + eor X2, X2, r10
> + eor X3, X3, r11
> + stmia r14!, {X0-X3}
> +
> + // x4-x7
> + __ldrd r8, r9, sp, 48
> + __ldrd r10, r11, sp, 56
> + add X4, r8, X4, ror #brot
> + add X5, r9, X5, ror #brot
> + ldmia r12!, {X0-X3}
> + add X6, r10, X6, ror #brot
> + add X7, r11, X7, ror #brot
> + _le32_bswap_4x X4, X5, X6, X7, r8, r9, r10
> + eor X4, X4, X0
> + eor X5, X5, X1
> + eor X6, X6, X2
> + eor X7, X7, X3
> + stmia r14!, {X4-X7}
> +
> + // x8-x15
> + pop {r0-r7} // (x8-x9,x12-x15,x10-x11)
> + __ldrd r8, r9, sp, 32
> + __ldrd r10, r11, sp, 40
> + add r0, r0, r8 // x8
> + add r1, r1, r9 // x9
> + add r6, r6, r10 // x10
> + add r7, r7, r11 // x11
> + _le32_bswap_4x r0, r1, r6, r7, r8, r9, r10
> + ldmia r12!, {r8-r11}
> + eor r0, r0, r8 // x8
> + eor r1, r1, r9 // x9
> + eor r6, r6, r10 // x10
> + eor r7, r7, r11 // x11
> + stmia r14!, {r0,r1,r6,r7}
> + ldmia r12!, {r0,r1,r6,r7}
> + __ldrd r8, r9, sp, 48
> + __ldrd r10, r11, sp, 56
> + add r2, r8, r2, ror #drot // x12
> + add r3, r9, r3, ror #drot // x13
> + add r4, r10, r4, ror #drot // x14
> + add r5, r11, r5, ror #drot // x15
> + _le32_bswap_4x r2, r3, r4, r5, r9, r10, r11
> + ldr r9, [sp, #72] // load LEN
> + eor r2, r2, r0 // x12
> + eor r3, r3, r1 // x13
> + eor r4, r4, r6 // x14
> + eor r5, r5, r7 // x15
> + subs r9, #64 // decrement and check LEN
> + stmia r14!, {r2-r5}
> +
> + beq .Ldone\@
> +
> +.Lprepare_for_next_block\@:
> +
> + // Stack: x0-x15 OUT IN LEN
> +
> + // Increment block counter (x12)
> + add r8, #1
> +
> + // Store updated (OUT, IN, LEN)
> + str r14, [sp, #64]
> + str r12, [sp, #68]
> + str r9, [sp, #72]
> +
> + mov r14, sp
> +
> + // Store updated block counter (x12)
> + str r8, [sp, #48]
> +
> + sub sp, #16
> +
> + // Reload state and do next block
> + ldmia r14!, {r0-r11} // load x0-x11
> + __strd r10, r11, sp, 8 // store x10-x11 before state
> + ldmia r14, {r10-r12,r14} // load x12-x15
> + b .Lnext_block\@
> +
> +.Lxor_slowpath\@:
> + // Slow path: < 64 bytes remaining, or unaligned input or output buffer.
> + // We handle it by storing the 64 bytes of keystream to the stack, then
> + // XOR-ing the needed portion with the data.
> +
> + // Allocate keystream buffer
> + sub sp, #64
> + mov r14, sp
> +
> + // Stack: ks0-ks15 x8-x9 x12-x15 x10-x11 orig_x0-orig_x15 OUT IN LEN
> + // Registers: r0-r7 are x0-x7; r8-r11 are free; r12 is IN; r14 is &ks0.
> + // x4-x7 are rotated by 'brot'; x12-x15 are rotated by 'drot'.
> +
> + // Save keystream for x0-x3
> + __ldrd r8, r9, sp, 96
> + __ldrd r10, r11, sp, 104
> + add X0, X0, r8
> + add X1, X1, r9
> + add X2, X2, r10
> + add X3, X3, r11
> + _le32_bswap_4x X0, X1, X2, X3, r8, r9, r10
> + stmia r14!, {X0-X3}
> +
> + // Save keystream for x4-x7
> + __ldrd r8, r9, sp, 112
> + __ldrd r10, r11, sp, 120
> + add X4, r8, X4, ror #brot
> + add X5, r9, X5, ror #brot
> + add X6, r10, X6, ror #brot
> + add X7, r11, X7, ror #brot
> + _le32_bswap_4x X4, X5, X6, X7, r8, r9, r10
> + add r8, sp, #64
> + stmia r14!, {X4-X7}
> +
> + // Save keystream for x8-x15
> + ldm r8, {r0-r7} // (x8-x9,x12-x15,x10-x11)
> + __ldrd r8, r9, sp, 128
> + __ldrd r10, r11, sp, 136
> + add r0, r0, r8 // x8
> + add r1, r1, r9 // x9
> + add r6, r6, r10 // x10
> + add r7, r7, r11 // x11
> + _le32_bswap_4x r0, r1, r6, r7, r8, r9, r10
> + stmia r14!, {r0,r1,r6,r7}
> + __ldrd r8, r9, sp, 144
> + __ldrd r10, r11, sp, 152
> + add r2, r8, r2, ror #drot // x12
> + add r3, r9, r3, ror #drot // x13
> + add r4, r10, r4, ror #drot // x14
> + add r5, r11, r5, ror #drot // x15
> + _le32_bswap_4x r2, r3, r4, r5, r9, r10, r11
> + stmia r14, {r2-r5}
> +
> + // Stack: ks0-ks15 unused0-unused7 x0-x15 OUT IN LEN
> + // Registers: r8 is block counter, r12 is IN.
> +
> + ldr r9, [sp, #168] // LEN
> + ldr r14, [sp, #160] // OUT
> + cmp r9, #64
> + mov r0, sp
> + movle r1, r9
> + movgt r1, #64
> + // r1 is number of bytes to XOR, in range [1, 64]
> +
> +.if __LINUX_ARM_ARCH__ < 6
> + orr r2, r12, r14
> + tst r2, #3 // IN or OUT misaligned?
> + bne .Lxor_next_byte\@
> +.endif
> +
> + // XOR a word at a time
> +.rept 16
> + subs r1, #4
> + blt .Lxor_words_done\@
> + ldr r2, [r12], #4
> + ldr r3, [r0], #4
> + eor r2, r2, r3
> + str r2, [r14], #4
> +.endr
> + b .Lxor_slowpath_done\@
> +.Lxor_words_done\@:
> + ands r1, r1, #3
> + beq .Lxor_slowpath_done\@
> +
> + // XOR a byte at a time
> +.Lxor_next_byte\@:
> + ldrb r2, [r12], #1
> + ldrb r3, [r0], #1
> + eor r2, r2, r3
> + strb r2, [r14], #1
> + subs r1, #1
> + bne .Lxor_next_byte\@
> +
> +.Lxor_slowpath_done\@:
> + subs r9, #64
> + add sp, #96
> + bgt .Lprepare_for_next_block\@
> +
> +.Ldone\@:
> +.endm // _chacha
> +
> +/*
> + * void chacha20_arm(u8 *out, const u8 *in, size_t len, const u32 key[8],
> + * const u32 iv[4]);
> + */
> +ENTRY(chacha20_arm)
> + cmp r2, #0 // len == 0?
> + bxeq lr
> +
> + push {r0-r2,r4-r11,lr}
> +
> + // Push state x0-x15 onto stack.
> + // Also store an extra copy of x10-x11 just before the state.
> +
> + ldr r4, [sp, #48] // iv
> + mov r0, sp
> + sub sp, #80
> +
> + // iv: x12-x15
> + ldm r4, {X12,X13,X14,X15}
> + stmdb r0!, {X12,X13,X14,X15}
> +
> + // key: x4-x11
> + __ldrd X8_X10, X9_X11, r3, 24
> + __strd X8_X10, X9_X11, sp, 8
> + stmdb r0!, {X8_X10, X9_X11}
> + ldm r3, {X4-X9_X11}
> + stmdb r0!, {X4-X9_X11}
> +
> + // constants: x0-x3
> + adrl X3, .Lexpand_32byte_k
> + ldm X3, {X0-X3}
> + __strd X0, X1, sp, 16
> + __strd X2, X3, sp, 24
> +
> + _chacha 20
> +
> + add sp, #76
> + pop {r4-r11, pc}
> +ENDPROC(chacha20_arm)
> +
> +/*
> + * void hchacha20_arm(const u32 state[16], u32 out[8]);
> + */
> +ENTRY(hchacha20_arm)
> + push {r1,r4-r11,lr}
> +
> + mov r14, r0
> + ldmia r14!, {r0-r11} // load x0-x11
> + push {r10-r11} // store x10-x11 to stack
> + ldm r14, {r10-r12,r14} // load x12-x15
> + sub sp, #8
> +
> + _chacha_permute 20
> +
> + // Skip over (unused0-unused1, x10-x11)
> + add sp, #16
> +
> + // Fix up rotations of x12-x15
> + ror X12, X12, #drot
> + ror X13, X13, #drot
> + pop {r4} // load 'out'
> + ror X14, X14, #drot
> + ror X15, X15, #drot
> +
> + // Store (x0-x3,x12-x15) to 'out'
> + stm r4, {X0,X1,X2,X3,X12,X13,X14,X15}
> +
> + pop {r4-r11,pc}
> +ENDPROC(hchacha20_arm)
> +
> +#ifdef CONFIG_KERNEL_MODE_NEON
> +/*
> + * This following NEON routine was ported from Andy Polyakov's implementation
> + * from CRYPTOGAMS. It begins with parts of the CRYPTOGAMS scalar routine,
> + * since certain NEON code paths actually branch to it.
> + */
> +
> .text
> #if defined(__thumb2__) || defined(__clang__)
> .syntax unified
> @@ -22,39 +484,6 @@
> #define ldrhsb ldrbhs
> #endif
>
> -.align 5
> -.Lsigma:
> -.long 0x61707865,0x3320646e,0x79622d32,0x6b206574 @ endian-neutral
> -.Lone:
> -.long 1,0,0,0
> -.word -1
> -
> -.align 5
> -ENTRY(chacha20_arm)
> - ldr r12,[sp,#0] @ pull pointer to counter and nonce
> - stmdb sp!,{r0-r2,r4-r11,lr}
> - cmp r2,#0 @ len==0?
> -#ifdef __thumb2__
> - itt eq
> -#endif
> - addeq sp,sp,#4*3
> - beq .Lno_data_arm
> - ldmia r12,{r4-r7} @ load counter and nonce
> - sub sp,sp,#4*(16) @ off-load area
> -#if __LINUX_ARM_ARCH__ < 7 && !defined(__thumb2__)
> - sub r14,pc,#100 @ .Lsigma
> -#else
> - adr r14,.Lsigma @ .Lsigma
> -#endif
> - stmdb sp!,{r4-r7} @ copy counter and nonce
> - ldmia r3,{r4-r11} @ load key
> - ldmia r14,{r0-r3} @ load sigma
> - stmdb sp!,{r4-r11} @ copy key
> - stmdb sp!,{r0-r3} @ copy sigma
> - str r10,[sp,#4*(16+10)] @ off-load "rx"
> - str r11,[sp,#4*(16+11)] @ off-load "rx"
> - b .Loop_outer_enter
> -
> .align 4
> .Loop_outer:
> ldmia sp,{r0-r9} @ load key material
> @@ -748,11 +1177,8 @@ ENTRY(chacha20_arm)
>
> .Ldone:
> add sp,sp,#4*(32+3)
> -.Lno_data_arm:
> ldmia sp!,{r4-r11,pc}
> -ENDPROC(chacha20_arm)
>
> -#ifdef CONFIG_KERNEL_MODE_NEON
> .align 5
> .Lsigma2:
> .long 0x61707865,0x3320646e,0x79622d32,0x6b206574 @ endian-neutral
> diff --git a/lib/zinc/chacha20/chacha20-arm64-cryptogams.S b/lib/zinc/chacha20/chacha20-arm64.S
> similarity index 100%
> rename from lib/zinc/chacha20/chacha20-arm64-cryptogams.S
> rename to lib/zinc/chacha20/chacha20-arm64.S
> diff --git a/lib/zinc/chacha20/chacha20.c b/lib/zinc/chacha20/chacha20.c
> index 4354b874a6a5..fc4f74fca653 100644
> --- a/lib/zinc/chacha20/chacha20.c
> +++ b/lib/zinc/chacha20/chacha20.c
> @@ -16,6 +16,8 @@
>
> #if defined(CONFIG_ZINC_ARCH_X86_64)
> #include "chacha20-x86_64-glue.h"
> +#elif defined(CONFIG_ZINC_ARCH_ARM) || defined(CONFIG_ZINC_ARCH_ARM64)
> +#include "chacha20-arm-glue.h"
> #else
> void __init chacha20_fpu_init(void)
> {
> --
> 2.19.0
>
^ permalink raw reply
* Re: [PATCH] net-tcp: /proc/sys/net/ipv4/tcp_probe_interval is a u32 not int
From: Eric Dumazet @ 2018-09-26 2:53 UTC (permalink / raw)
To: Maciej Żenczykowski, Maciej Żenczykowski,
David S . Miller, Eric Dumazet
Cc: netdev
In-Reply-To: <20180926004103.163145-1-zenczykowski@gmail.com>
On 09/25/2018 05:41 PM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski <maze@google.com>
>
> (fix documentation and sysctl access to treat it as such)
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> ---
While we are at it, we probably should add sane limits,
given tcp_mtu_check_reprobe() does :
u32 interval = net->ipv4.sysctl_tcp_probe_interval;
...
if (unlikely(delta >= interval * HZ)) {
A limit of UINT_MAX / HZ would avoid an overflow I guess.
^ permalink raw reply
* Re: [PATCH net RFT] bnxt_en: Fix TX timeout during netpoll.
From: Michael Chan @ 2018-09-26 2:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Eric Dumazet, Song Liu, David Miller, Netdev
In-Reply-To: <CANn89iLiYE81yDHpfV3UWUVFxrbqJJiTkA6Tg6DAShAwdBeQ6w@mail.gmail.com>
On Tue, Sep 25, 2018 at 7:25 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Tue, Sep 25, 2018 at 7:15 PM Michael Chan <michael.chan@broadcom.com> wrote:
> >
> > On Tue, Sep 25, 2018 at 4:11 PM Michael Chan <michael.chan@broadcom.com> wrote:
> > >
> > > On Tue, Sep 25, 2018 at 3:15 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > >
> > > >
> > > > It seems bnx2 should have a similar issue ?
> > > >
> > >
> > > Yes, I think so. The MSIX mode in bnx2 is also auto-masking, meaning
> > > that MSIX will only assert once after it is ARMed. If we return from
> > > ->poll() when budget of 0 is reached without ARMing, we may not get
> > > another MSIX.
> > >
> >
> > On second thought, I think bnx2 is ok. If netpoll is polling on the
> > TX packets and reaching budget of 0 and returning, the INT_ACK_CMD
> > register is untouched. bnx2 uses the status block for events and the
> > producers/consumers are cumulative. So there is no need to ACK the
> > status block unless ARMing for interrupts. If there is an IRQ about
> > to be fired, it won't be affected by the polling done by netpoll.
> >
> > In the case of bnxt, a completion ring is used for the events. The
> > polling done by netpoll will cause the completion ring to be ACKed as
> > entries are processed. ACKing the completion ring without ARMing may
> > cause future IRQs to be disabled for that ring.
>
> About bnxt : Are you sure it is all about IRQ problems ?
I'm pretty sure, because FB first reported TX timeouts followed by
ring reset failures when running netconsole. These ring reset
failures are caused by IRQs no longer working on some rings.
>
> What if the whole ring buffer is is filled, then all entries
> are processed from netpoll.
>
> If cp_raw_cons becomes too high without the NIC knowing its (updated)
> value, maybe no IRQ can be generated anymore because
> of some wrapping issue (based on ring size)
Good point. We have logic to handle that. We will ACK the ring at
least once every tp->tx_wake_thresh TX packets. But this logic fails
when the budget is 0, so I need to send a revised patch take care of
this one case.
>
> I guess that in order to test this, we would need something bursting
> 16000 messages while holding napi->poll_owner.
> The (single) IRQ would set/grab the SCHED bit but the cpu responsible
> to service this (soft)irq would spin for the whole test,
> and no more IRQ should be fired really.
Right, not easy to hit. But it should be handled by my v2 patch. Thanks.
^ permalink raw reply
* [PATCH net-next] net: smsc: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-26 9:06 UTC (permalink / raw)
To: davem, nico, steve.glendinning, robert.jarzmik
Cc: linux-kernel, netdev, YueHaibing
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/smsc/smc911x.c | 3 ++-
drivers/net/ethernet/smsc/smc91x.c | 3 ++-
drivers/net/ethernet/smsc/smsc911x.c | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smc911x.c b/drivers/net/ethernet/smsc/smc911x.c
index b1b53f6..8355dfb 100644
--- a/drivers/net/ethernet/smsc/smc911x.c
+++ b/drivers/net/ethernet/smsc/smc911x.c
@@ -513,7 +513,8 @@ static void smc911x_hardware_send_pkt(struct net_device *dev)
* now, or set the card to generates an interrupt when ready
* for the packet.
*/
-static int smc911x_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+smc911x_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct smc911x_local *lp = netdev_priv(dev);
unsigned int free;
diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index b944828..8d6cff8 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -638,7 +638,8 @@ static void smc_hardware_send_pkt(unsigned long data)
* now, or set the card to generates an interrupt when ready
* for the packet.
*/
-static int smc_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+smc_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct smc_local *lp = netdev_priv(dev);
void __iomem *ioaddr = lp->base;
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index c009407..99a5a8a 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -1786,7 +1786,8 @@ static int smsc911x_stop(struct net_device *dev)
}
/* Entry point for transmitting a packet */
-static int smsc911x_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+smsc911x_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct smsc911x_data *pdata = netdev_priv(dev);
unsigned int freespace;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next] net: ti: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-26 9:09 UTC (permalink / raw)
To: davem, f.fainelli, grygorii.strashko, w-kwok2, m-karicheri2,
lukas, bgolaszewski, ivan.khoronzhuk, dan.carpenter
Cc: linux-kernel, netdev, linux-omap, YueHaibing
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/ti/cpmac.c | 2 +-
drivers/net/ethernet/ti/davinci_emac.c | 2 +-
drivers/net/ethernet/ti/netcp_core.c | 8 ++++----
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpmac.c b/drivers/net/ethernet/ti/cpmac.c
index 9b8a30b..64c45eb 100644
--- a/drivers/net/ethernet/ti/cpmac.c
+++ b/drivers/net/ethernet/ti/cpmac.c
@@ -544,7 +544,7 @@ static int cpmac_poll(struct napi_struct *napi, int budget)
}
-static int cpmac_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t cpmac_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
int queue;
unsigned int len;
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index f270bee..b83f32d 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -943,7 +943,7 @@ static void emac_tx_handler(void *token, int len, int status)
*
* Returns success(NETDEV_TX_OK) or error code (typically out of desc's)
*/
-static int emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev)
+static netdev_tx_t emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev)
{
struct device *emac_dev = &ndev->dev;
int ret_code;
diff --git a/drivers/net/ethernet/ti/netcp_core.c b/drivers/net/ethernet/ti/netcp_core.c
index 1f61226..2d8cfe8 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -1270,7 +1270,8 @@ static int netcp_tx_submit_skb(struct netcp_intf *netcp,
}
/* Submit the packet */
-static int netcp_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev)
+static netdev_tx_t
+netcp_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev)
{
struct netcp_intf *netcp = netdev_priv(ndev);
struct netcp_stats *tx_stats = &netcp->stats;
@@ -1290,7 +1291,7 @@ static int netcp_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev)
dev_warn(netcp->ndev_dev, "padding failed (%d), packet dropped\n",
ret);
tx_stats->tx_dropped++;
- return ret;
+ return NETDEV_TX_BUSY;
}
skb->len = NETCP_MIN_PACKET_SIZE;
}
@@ -1298,7 +1299,6 @@ static int netcp_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev)
desc = netcp_tx_map_skb(skb, netcp);
if (unlikely(!desc)) {
netif_stop_subqueue(ndev, subqueue);
- ret = -ENOBUFS;
goto drop;
}
@@ -1319,7 +1319,7 @@ static int netcp_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev)
if (desc)
netcp_free_tx_desc_chain(netcp, desc, sizeof(*desc));
dev_kfree_skb(skb);
- return ret;
+ return NETDEV_TX_BUSY;
}
int netcp_txpipe_close(struct netcp_tx_pipe *tx_pipe)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next] net: faraday: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-26 9:13 UTC (permalink / raw)
To: davem, andrew, f.fainelli, joel, sam, garsilva
Cc: linux-kernel, netdev, YueHaibing
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/faraday/ftgmac100.c | 4 ++--
drivers/net/ethernet/faraday/ftmac100.c | 7 ++++---
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
index d8ead7e..4d67322 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -712,8 +712,8 @@ static bool ftgmac100_prep_tx_csum(struct sk_buff *skb, u32 *csum_vlan)
return skb_checksum_help(skb) == 0;
}
-static int ftgmac100_hard_start_xmit(struct sk_buff *skb,
- struct net_device *netdev)
+static netdev_tx_t ftgmac100_hard_start_xmit(struct sk_buff *skb,
+ struct net_device *netdev)
{
struct ftgmac100 *priv = netdev_priv(netdev);
struct ftgmac100_txdes *txdes, *first;
diff --git a/drivers/net/ethernet/faraday/ftmac100.c b/drivers/net/ethernet/faraday/ftmac100.c
index a1197d3..570caeb 100644
--- a/drivers/net/ethernet/faraday/ftmac100.c
+++ b/drivers/net/ethernet/faraday/ftmac100.c
@@ -634,8 +634,8 @@ static void ftmac100_tx_complete(struct ftmac100 *priv)
;
}
-static int ftmac100_xmit(struct ftmac100 *priv, struct sk_buff *skb,
- dma_addr_t map)
+static netdev_tx_t ftmac100_xmit(struct ftmac100 *priv, struct sk_buff *skb,
+ dma_addr_t map)
{
struct net_device *netdev = priv->netdev;
struct ftmac100_txdes *txdes;
@@ -1016,7 +1016,8 @@ static int ftmac100_stop(struct net_device *netdev)
return 0;
}
-static int ftmac100_hard_start_xmit(struct sk_buff *skb, struct net_device *netdev)
+static netdev_tx_t
+ftmac100_hard_start_xmit(struct sk_buff *skb, struct net_device *netdev)
{
struct ftmac100 *priv = netdev_priv(netdev);
dma_addr_t map;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next] net: ovs: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-26 9:15 UTC (permalink / raw)
To: davem, pshelar; +Cc: linux-kernel, netdev, dev, YueHaibing
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/openvswitch/vport-internal_dev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/openvswitch/vport-internal_dev.c b/net/openvswitch/vport-internal_dev.c
index bb95c43..26f71cb 100644
--- a/net/openvswitch/vport-internal_dev.c
+++ b/net/openvswitch/vport-internal_dev.c
@@ -43,7 +43,8 @@ static struct internal_dev *internal_dev_priv(struct net_device *netdev)
}
/* Called with rcu_read_lock_bh. */
-static int internal_dev_xmit(struct sk_buff *skb, struct net_device *netdev)
+static netdev_tx_t
+internal_dev_xmit(struct sk_buff *skb, struct net_device *netdev)
{
int len, err;
@@ -62,7 +63,7 @@ static int internal_dev_xmit(struct sk_buff *skb, struct net_device *netdev)
} else {
netdev->stats.tx_errors++;
}
- return 0;
+ return NETDEV_TX_OK;
}
static int internal_dev_open(struct net_device *netdev)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next] net: caif: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-26 9:27 UTC (permalink / raw)
To: davem, dmitry.tarnyagin; +Cc: linux-kernel, netdev, YueHaibing
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/caif/caif_hsi.c | 10 +++++-----
drivers/net/caif/caif_serial.c | 7 +++++--
drivers/net/caif/caif_spi.c | 6 +++---
drivers/net/caif/caif_virtio.c | 2 +-
net/caif/chnl_net.c | 3 ++-
5 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/net/caif/caif_hsi.c b/drivers/net/caif/caif_hsi.c
index 433a14b..70c449e 100644
--- a/drivers/net/caif/caif_hsi.c
+++ b/drivers/net/caif/caif_hsi.c
@@ -1006,7 +1006,7 @@ static void cfhsi_aggregation_tout(struct timer_list *t)
cfhsi_start_tx(cfhsi);
}
-static int cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct cfhsi *cfhsi = NULL;
int start_xfer = 0;
@@ -1014,7 +1014,7 @@ static int cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
int prio;
if (!dev)
- return -EINVAL;
+ return NETDEV_TX_BUSY;
cfhsi = netdev_priv(dev);
@@ -1048,7 +1048,7 @@ static int cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
if (WARN_ON(test_bit(CFHSI_SHUTDOWN, &cfhsi->bits))) {
spin_unlock_bh(&cfhsi->lock);
cfhsi_abort_tx(cfhsi);
- return -EINVAL;
+ return NETDEV_TX_BUSY;
}
/* Send flow off if number of packets is above high water mark. */
@@ -1072,7 +1072,7 @@ static int cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
spin_unlock_bh(&cfhsi->lock);
if (aggregate_ready)
cfhsi_start_tx(cfhsi);
- return 0;
+ return NETDEV_TX_OK;
}
/* Delete inactivity timer if started. */
@@ -1102,7 +1102,7 @@ static int cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
queue_work(cfhsi->wq, &cfhsi->wake_up_work);
}
- return 0;
+ return NETDEV_TX_OK;
}
static const struct net_device_ops cfhsi_netdevops;
diff --git a/drivers/net/caif/caif_serial.c b/drivers/net/caif/caif_serial.c
index a0f954f..acb3264 100644
--- a/drivers/net/caif/caif_serial.c
+++ b/drivers/net/caif/caif_serial.c
@@ -275,7 +275,7 @@ static int handle_tx(struct ser_device *ser)
return tty_wr;
}
-static int caif_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t caif_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ser_device *ser;
@@ -290,7 +290,10 @@ static int caif_xmit(struct sk_buff *skb, struct net_device *dev)
ser->common.flowctrl(ser->dev, OFF);
skb_queue_tail(&ser->head, skb);
- return handle_tx(ser);
+ if (handle_tx(ser))
+ return NETDEV_TX_BUSY;
+
+ return NETDEV_TX_OK;
}
diff --git a/drivers/net/caif/caif_spi.c b/drivers/net/caif/caif_spi.c
index d28a139..9040658 100644
--- a/drivers/net/caif/caif_spi.c
+++ b/drivers/net/caif/caif_spi.c
@@ -486,12 +486,12 @@ static void cfspi_xfer_done_cb(struct cfspi_ifc *ifc)
complete(&cfspi->comp);
}
-static int cfspi_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t cfspi_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct cfspi *cfspi = NULL;
unsigned long flags;
if (!dev)
- return -EINVAL;
+ return NETDEV_TX_BUSY;
cfspi = netdev_priv(dev);
@@ -512,7 +512,7 @@ static int cfspi_xmit(struct sk_buff *skb, struct net_device *dev)
cfspi->cfdev.flowctrl(cfspi->ndev, 0);
}
- return 0;
+ return NETDEV_TX_OK;
}
int cfspi_rxfrm(struct cfspi *cfspi, u8 *buf, size_t len)
diff --git a/drivers/net/caif/caif_virtio.c b/drivers/net/caif/caif_virtio.c
index 2814e0d..f5507db 100644
--- a/drivers/net/caif/caif_virtio.c
+++ b/drivers/net/caif/caif_virtio.c
@@ -519,7 +519,7 @@ static struct buf_info *cfv_alloc_and_copy_to_shm(struct cfv_info *cfv,
}
/* Put the CAIF packet on the virtio ring and kick the receiver */
-static int cfv_netdev_tx(struct sk_buff *skb, struct net_device *netdev)
+static netdev_tx_t cfv_netdev_tx(struct sk_buff *skb, struct net_device *netdev)
{
struct cfv_info *cfv = netdev_priv(netdev);
struct buf_info *buf_info;
diff --git a/net/caif/chnl_net.c b/net/caif/chnl_net.c
index 13e2ae6..30be426 100644
--- a/net/caif/chnl_net.c
+++ b/net/caif/chnl_net.c
@@ -211,7 +211,8 @@ static void chnl_flowctrl_cb(struct cflayer *layr, enum caif_ctrlcmd flow,
}
}
-static int chnl_net_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+chnl_net_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct chnl_net *priv;
struct cfpkt *pkt = NULL;
--
1.8.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox