* general protection fault in reuseport_add_sock
From: syzbot @ 2019-02-16 7:01 UTC (permalink / raw)
To: ast, daniel, davem, kafai, linux-kernel, lucien.xin, netdev,
songliubraving, syzkaller-bugs, yhs
Hello,
syzbot found the following crash on:
HEAD commit: f9bcc9f3ee4f net: ethernet: freescale: set FEC ethtool reg..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=158a10f3400000
kernel config: https://syzkaller.appspot.com/x/.config?x=8f00801d7b7c4fe6
dashboard link: https://syzkaller.appspot.com/bug?extid=675ee297acac988852c1
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+675ee297acac988852c1@syzkaller.appspotmail.com
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
kobject: 'loop2' (000000005809b865): kobject_uevent_env
CPU: 1 PID: 14725 Comm: syz-executor.3 Not tainted 5.0.0-rc5+ #78
kobject: 'loop2' (000000005809b865): fill_kobj_path: path
= '/devices/virtual/block/loop2'
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:reuseport_add_sock+0x187/0x8f0 net/core/sock_reuseport.c:170
Code: e8 ce 4e f2 fb 66 83 fb 01 0f 85 54 06 00 00 e8 5f 4d f2 fb 4d 8d 74
24 12 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <0f> b6 14 02 4c
89 f0 83 e0 07 83 c0 01 38 d0 7c 08 84 d2 0f 85 fc
RSP: 0018:ffff888066abfca0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffc9000c432000
RDX: 0000000000000002 RSI: ffffffff857d8dc1 RDI: 0000000000000005
kobject: 'loop4' (00000000b88abefc): kobject_uevent_env
RBP: ffff888066abfd08 R08: ffff888064ff43c0 R09: fffffbfff1264fcd
R10: fffffbfff1264fcc R11: ffffffff89327e63 R12: 0000000000000000
R13: ffff888098d9c800 R14: 0000000000000012 R15: 0000000000000000
kobject: 'loop4' (00000000b88abefc): fill_kobj_path: path
= '/devices/virtual/block/loop4'
FS: 00007f02a40cf700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004563fa CR3: 000000009ae04000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__sctp_hash_endpoint net/sctp/input.c:758 [inline]
sctp_hash_endpoint+0x523/0x5d0 net/sctp/input.c:786
sctp_listen_start net/sctp/socket.c:7967 [inline]
sctp_inet_listen+0x5b2/0x880 net/sctp/socket.c:8022
kobject: 'loop5' (0000000099e34deb): kobject_uevent_env
__sys_listen+0x19b/0x270 net/socket.c:1515
kobject: 'loop5' (0000000099e34deb): fill_kobj_path: path
= '/devices/virtual/block/loop5'
__do_sys_listen net/socket.c:1524 [inline]
__se_sys_listen net/socket.c:1522 [inline]
__x64_sys_listen+0x54/0x80 net/socket.c:1522
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457e29
kobject: 'loop1' (00000000259faa1c): kobject_uevent_env
Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f02a40cec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000032
kobject: 'loop1' (00000000259faa1c): fill_kobj_path: path
= '/devices/virtual/block/loop1'
RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 0000000000457e29
RDX: 0000000000000000 RSI: 0000000100000001 RDI: 0000000000000005
RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f02a40cf6d4
R13: 00000000004c3a2d R14: 00000000004d6940 R15: 00000000ffffffff
Modules linked in:
---[ end trace 3ce5847aad8cc1f0 ]---
RIP: 0010:reuseport_add_sock+0x187/0x8f0 net/core/sock_reuseport.c:170
Code: e8 ce 4e f2 fb 66 83 fb 01 0f 85 54 06 00 00 e8 5f 4d f2 fb 4d 8d 74
24 12 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <0f> b6 14 02 4c
89 f0 83 e0 07 83 c0 01 38 d0 7c 08 84 d2 0f 85 fc
RSP: 0018:ffff888066abfca0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffc9000c432000
RDX: 0000000000000002 RSI: ffffffff857d8dc1 RDI: 0000000000000005
RBP: ffff888066abfd08 R08: ffff888064ff43c0 R09: fffffbfff1264fcd
R10: fffffbfff1264fcc R11: ffffffff89327e63 R12: 0000000000000000
R13: ffff888098d9c800 R14: 0000000000000012 R15: 0000000000000000
FS: 00007f02a40cf700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004563fa CR3: 000000009ae04000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
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 __vunmap
From: syzbot @ 2019-02-16 7:01 UTC (permalink / raw)
To: davem, herbert, linux-kernel, netdev, steffen.klassert,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: cb5b020a8d38 Revert "exec: load_script: don't blindly trun..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13c2886cc00000
kernel config: https://syzkaller.appspot.com/x/.config?x=ee434566c893c7b1
dashboard link: https://syzkaller.appspot.com/bug?extid=39d3a56f2f717d237007
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+39d3a56f2f717d237007@syzkaller.appspotmail.com
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 23956 Comm: syz-executor.3 Not tainted 5.0.0-rc6+ #72
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__vunmap+0x68/0x400 mm/vmalloc.c:1508
Code: 85 e4 0f 85 de 02 00 00 e8 45 c7 d0 ff 4c 89 ef e8 9d 82 ff ff 48 ba
00 00 00 00 00 fc ff df 48 8d 78 48 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f
85 50 03 00 00 4c 8b 60 48 4d 85 e4 0f 84 bd 02 00
RSP: 0018:ffff88809613f4b0 EFLAGS: 00010206
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000009
RDX: dffffc0000000000 RSI: 0000000000000004 RDI: 0000000000000048
RBP: ffff88809613f4f0 R08: 1ffffffff1146d18 R09: fffffbfff1146d19
R10: fffffbfff1146d18 R11: ffffffff88a368c3 R12: 0000000000000000
R13: 0000004e00000000 R14: ffffe8ffffc71948 R15: 0000607f51471948
FS: 00007fa9e49b6700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc7182d2000 CR3: 000000004b7bb000 CR4: 00000000001426f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
vfree+0x8d/0x140 mm/vmalloc.c:1597
ipcomp_free_scratches+0xc0/0x150 net/xfrm/xfrm_ipcomp.c:216
ipcomp_free_data net/xfrm/xfrm_ipcomp.c:325 [inline]
ipcomp_init_state+0x76d/0xa10 net/xfrm/xfrm_ipcomp.c:377
ipcomp6_init_state+0xc9/0x880 net/ipv6/ipcomp6.c:165
__xfrm_init_state+0x557/0xef0 net/xfrm/xfrm_state.c:2302
xfrm_init_state+0x1e/0x80 net/xfrm/xfrm_state.c:2328
pfkey_msg2xfrm_state net/key/af_key.c:1307 [inline]
pfkey_add+0x1da7/0x2fd0 net/key/af_key.c:1524
pfkey_process+0x6d2/0x810 net/key/af_key.c:2844
pfkey_sendmsg+0x40b/0xbe0 net/key/af_key.c:3683
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x3e2/0x930 net/socket.c:2114
__sys_sendmmsg+0x1c3/0x4e0 net/socket.c:2209
__do_sys_sendmmsg net/socket.c:2238 [inline]
__se_sys_sendmmsg net/socket.c:2235 [inline]
__x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2235
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457e29
Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fa9e49b5c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 0000000000457e29
RDX: 0400000000000142 RSI: 0000000020000180 RDI: 0000000000000004
RBP: 000000000073c040 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa9e49b66d4
R13: 00000000004c4dd8 R14: 00000000004d8a70 R15: 00000000ffffffff
Modules linked in:
kobject: 'loop4' (00000000647dbe39): kobject_uevent_env
kobject: 'loop4' (00000000647dbe39): fill_kobj_path: path
= '/devices/virtual/block/loop4'
kobject: 'kvm' (0000000078525e49): kobject_uevent_env
kobject: 'kvm' (0000000078525e49): fill_kobj_path: path
= '/devices/virtual/misc/kvm'
---[ end trace 25e2186da6a07104 ]---
RIP: 0010:__vunmap+0x68/0x400 mm/vmalloc.c:1508
IPVS: ftp: loaded support on port[0] = 21
Code: 85 e4 0f 85 de 02 00 00 e8 45 c7 d0 ff 4c 89 ef e8 9d 82 ff ff 48 ba
00 00 00 00 00 fc ff df 48 8d 78 48 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f
85 50 03 00 00 4c 8b 60 48 4d 85 e4 0f 84 bd 02 00
kobject: 'kvm' (0000000078525e49): kobject_uevent_env
kobject: 'lo' (00000000532a5fa3): kobject_add_internal: parent: 'net',
set: 'devices'
kobject: 'kvm' (0000000078525e49): fill_kobj_path: path
= '/devices/virtual/misc/kvm'
RSP: 0018:ffff88809613f4b0 EFLAGS: 00010206
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000009
kobject: 'kvm' (0000000078525e49): kobject_uevent_env
kobject: 'lo' (00000000532a5fa3): kobject_uevent_env
RDX: dffffc0000000000 RSI: 0000000000000004 RDI: 0000000000000048
kobject: 'kvm' (0000000078525e49): fill_kobj_path: path
= '/devices/virtual/misc/kvm'
RBP: ffff88809613f4f0 R08: 1ffffffff1146d18 R09: fffffbfff1146d19
kobject: 'lo' (00000000532a5fa3): fill_kobj_path: path
= '/devices/virtual/net/lo'
R10: fffffbfff1146d18 R11: ffffffff88a368c3 R12: 0000000000000000
R13: 0000004e00000000 R14: ffffe8ffffc71948 R15: 0000607f51471948
kobject: 'loop4' (00000000647dbe39): kobject_uevent_env
kobject: 'loop4' (00000000647dbe39): fill_kobj_path: path
= '/devices/virtual/block/loop4'
FS: 00007fa9e49b6700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
kobject: 'queues' (00000000ae77e0e8): kobject_add_internal: parent: 'lo',
set: '<NULL>'
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000070a158 CR3: 000000004b7bb000 CR4: 00000000001406e0
kobject: 'loop5' (00000000975607f3): kobject_uevent_env
kobject: 'queues' (00000000ae77e0e8): kobject_uevent_env
kobject: 'loop5' (00000000975607f3): fill_kobj_path: path
= '/devices/virtual/block/loop5'
kobject: 'queues' (00000000ae77e0e8): kobject_uevent_env: filter function
caused the event to drop!
kobject: 'rx-0' (000000002f4df33a): kobject_add_internal: parent: 'queues',
set: 'queues'
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
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
* INFO: task hung in __flush_work
From: syzbot @ 2019-02-16 7:01 UTC (permalink / raw)
To: aviadye, borisp, daniel, davejwatson, davem, john.fastabend,
linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 90cadbbf341d Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10a565c7400000
kernel config: https://syzkaller.appspot.com/x/.config?x=9d41c8529d7e7362
dashboard link: https://syzkaller.appspot.com/bug?extid=aa0b64a57e300a1c6bcc
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12a6629b400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1222d29b400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+aa0b64a57e300a1c6bcc@syzkaller.appspotmail.com
TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending
cookies. Check SNMP counters.
INFO: task syz-executor925:7871 blocked for more than 140 seconds.
Not tainted 4.20.0-rc7+ #360
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor925 D19912 7871 7870 0x00000004
Call Trace:
context_switch kernel/sched/core.c:2831 [inline]
__schedule+0x86c/0x1ed0 kernel/sched/core.c:3472
schedule+0xfe/0x460 kernel/sched/core.c:3516
schedule_timeout+0x1cc/0x260 kernel/time/timer.c:1780
do_wait_for_common kernel/sched/completion.c:83 [inline]
__wait_for_common kernel/sched/completion.c:104 [inline]
wait_for_common kernel/sched/completion.c:115 [inline]
wait_for_completion+0x427/0x8a0 kernel/sched/completion.c:136
__flush_work+0x59c/0x9b0 kernel/workqueue.c:2917
__cancel_work_timer+0x4ba/0x820 kernel/workqueue.c:3004
cancel_delayed_work_sync+0x1a/0x20 kernel/workqueue.c:3136
tls_sw_free_resources_tx+0x1df/0xcf0 net/tls/tls_sw.c:1795
tls_sk_proto_close+0x602/0x750 net/tls/tls_main.c:280
inet_release+0x104/0x1f0 net/ipv4/af_inet.c:428
inet6_release+0x50/0x70 net/ipv6/af_inet6.c:458
__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:188 [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:0x401010
Code: 01 f0 ff ff 0f 83 b0 0a 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
44 00 00 83 3d bd 16 2d 00 00 75 14 b8 03 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 0f 83 84 0a 00 00 c3 48 83 ec 08 e8 3a 01 00 00
RSP: 002b:00007ffec7856f48 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000401010
RDX: 00000000e0ffffff RSI: 00000000200005c0 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401f20
R13: 0000000000401fb0 R14: 0000000000000000 R15: 0000000000000000
Showing all locks held in the system:
2 locks held by kworker/0:0/5:
#0: 000000006d11dec0 ((wq_completion)"events"){+.+.}, at:
__write_once_size include/linux/compiler.h:218 [inline]
#0: 000000006d11dec0 ((wq_completion)"events"){+.+.}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 000000006d11dec0 ((wq_completion)"events"){+.+.}, at: atomic64_set
include/asm-generic/atomic-instrumented.h:40 [inline]
#0: 000000006d11dec0 ((wq_completion)"events"){+.+.}, at: atomic_long_set
include/asm-generic/atomic-long.h:59 [inline]
#0: 000000006d11dec0 ((wq_completion)"events"){+.+.}, at: set_work_data
kernel/workqueue.c:617 [inline]
#0: 000000006d11dec0 ((wq_completion)"events"){+.+.}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
#0: 000000006d11dec0 ((wq_completion)"events"){+.+.}, at:
process_one_work+0xb43/0x1c40 kernel/workqueue.c:2124
#1: 00000000ccfe6c9a
((work_completion)(&(&sw_ctx_tx->tx_work.work)->work)){+.+.}, at:
process_one_work+0xb9a/0x1c40 kernel/workqueue.c:2128
1 lock held by khungtaskd/1014:
#0: 00000000153ed952 (rcu_read_lock){....}, at:
debug_show_all_locks+0xd0/0x424 kernel/locking/lockdep.c:4379
1 lock held by rsyslogd/7757:
#0: 0000000034b64696 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x1bb/0x200
fs/file.c:766
2 locks held by getty/7847:
#0: 00000000d063ffb7 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: 0000000045d4d183 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by getty/7848:
#0: 00000000dda11696 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: 00000000a02eb135 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by getty/7849:
#0: 0000000013f4e4e1 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: 00000000f6bb4c99 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by getty/7850:
#0: 00000000daef1117 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: 00000000229b8dfc (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by getty/7851:
#0: 000000005093d448 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: 00000000bca705ed (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by getty/7852:
#0: 000000000f124289 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: 00000000a9adbb34 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by getty/7853:
#0: 0000000027476b58 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x32/0x40 drivers/tty/tty_ldsem.c:353
#1: 000000007cc578ce (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x335/0x1e80 drivers/tty/n_tty.c:2154
2 locks held by syz-executor925/7871:
#0: 00000000997b6df5 (&sb->s_type->i_mutex_key#11){+.+.}, at: inode_lock
include/linux/fs.h:757 [inline]
#0: 00000000997b6df5 (&sb->s_type->i_mutex_key#11){+.+.}, at:
__sock_release+0x8b/0x250 net/socket.c:578
#1: 00000000af711cb5 (sk_lock-AF_INET6){+.+.}, at: lock_sock
include/net/sock.h:1502 [inline]
#1: 00000000af711cb5 (sk_lock-AF_INET6){+.+.}, at:
wait_on_pending_writer+0x27c/0x5b0 net/tls/tls_main.c:89
=============================================
NMI backtrace for cpu 1
CPU: 1 PID: 1014 Comm: khungtaskd Not tainted 4.20.0-rc7+ #360
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+0x1d3/0x2c6 lib/dump_stack.c:113
nmi_cpu_backtrace.cold.4+0x63/0xa2 lib/nmi_backtrace.c:101
nmi_trigger_cpumask_backtrace+0x1c2/0x22c lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_all_cpu_backtrace include/linux/nmi.h:146 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:205 [inline]
watchdog+0xb51/0x1060 kernel/hung_task.c:289
kthread+0x35a/0x440 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0 skipped: idling at native_safe_halt+0x6/0x10
arch/x86/include/asm/irqflags.h:57
---
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.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH net-next] net: hns3: make function hclge_set_all_vf_rst() static
From: Wei Yongjun @ 2019-02-16 8:15 UTC (permalink / raw)
To: Yisen Zhuang, Salil Mehta, Huazhong Tan, Yunsheng Lin, Peng Li,
Jian Shen, Fuyun Liang
Cc: Wei Yongjun, netdev, kernel-janitors
Fixes the following sparse warning:
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c:2431:5: warning:
symbol 'hclge_set_all_vf_rst' was not declared. Should it be static?
Fixes: aa5c4f175be6 ("net: hns3: add reset handling for VF when doing PF reset")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index ab90108..362b03c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2428,7 +2428,7 @@ static int hclge_set_vf_rst(struct hclge_dev *hdev, int func_id, bool reset)
return hclge_cmd_send(&hdev->hw, &desc, 1);
}
-int hclge_set_all_vf_rst(struct hclge_dev *hdev, bool reset)
+static int hclge_set_all_vf_rst(struct hclge_dev *hdev, bool reset)
{
int i;
^ permalink raw reply related
* [PATCH net-next] netfilter: ipt_CLUSTERIP: make symbol 'cip_netdev_notifier' static
From: Wei Yongjun @ 2019-02-16 8:16 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Taehee Yoo
Cc: Wei Yongjun, netfilter-devel, coreteam, netdev, kernel-janitors
Fixes the following sparse warnings:
net/ipv4/netfilter/ipt_CLUSTERIP.c:867:23: warning:
symbol 'cip_netdev_notifier' was not declared. Should it be static?
Fixes: 5a86d68bcf02 ("netfilter: ipt_CLUSTERIP: fix deadlock in netns exit routine")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
net/ipv4/netfilter/ipt_CLUSTERIP.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/netfilter/ipt_CLUSTERIP.c b/net/ipv4/netfilter/ipt_CLUSTERIP.c
index b61977d..91b369b 100644
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -864,7 +864,7 @@ static void clusterip_net_exit(struct net *net)
.size = sizeof(struct clusterip_net),
};
-struct notifier_block cip_netdev_notifier = {
+static struct notifier_block cip_netdev_notifier = {
.notifier_call = clusterip_netdev_event
};
^ permalink raw reply related
* Re: [PATCH RFC] net: bridge: don't flood known multicast traffic when snooping is enabled
From: Nikolay Aleksandrov @ 2019-02-16 8:05 UTC (permalink / raw)
To: Linus Lüssing; +Cc: netdev, roopa, wkok, anuradhak, bridge, davem, stephen
In-Reply-To: <20190215171332.GA1472@otheros>
On 15/02/2019 19:13, Linus Lüssing wrote:
> On Fri, Feb 15, 2019 at 03:04:27PM +0200, Nikolay Aleksandrov wrote:
>> Every user would expect to have traffic forwarded only to the configured
>> mdb destination when snooping is enabled, instead now to get that one
>> needs to enable both snooping and querier. Enabling querier on all
>> switches could be problematic and is not a good solution,
>
> There is no need to set the querier on all snooping switches.
> br_multicast_querier_exists() checks if a querier exists on the
> link in general, not if this particular host/bridge is a querier.
>
We need a generic solution for the case of existing mdst and no querier.
More below.
>
>> for example as summarized by our multicast experts:
>> "every switch would send an IGMP query
>
> What? RFC3810, section 7.1 says:
>
> "If it is the case, a querier election mechanism (described in
> section 7.6.2) is used to elect a single multicast router to be
> in Querier state. [...] Nevertheless, it is only the [elected] Querier
> that sends periodical or triggered query messages on the subnet."
> >> for any random multicast traffic it
>> received across the entire domain and it would send it forever as long as a
>> host exists wanting that stream even if it has no downstream/directly
>> connected receivers"
>
This was taken out of context and it's my bad, I think everyone is aware
of the election process, please nevermind the above statement.
[snip]>
>
> Have you done some tests with this change yet, Nikolay?
>
You've raised good questions, IPv6 indeed needs more work - we'll have to flood
link-local packets etc. but I wanted to have a discussion about no querier/existing mdst.
To simplify we can modify the patch and have traffic forwarded to the proper ports when an
mdst exists and there is no querier for both unsolicited report and user-added entry.
We can keep the current behaviour for unknown traffic with and without querier.
This would align it closer to what other vendors currently do as well IIRC.
What do you think ?
Thanks,
Nik
^ permalink raw reply
* [PATCH] net: sched: using kfree_rcu() to simplify the code
From: Wei Yongjun @ 2019-02-16 8:19 UTC (permalink / raw)
To: Jamal Hadi Salim, Cong Wang, Jiri Pirko
Cc: Wei Yongjun, netdev, kernel-janitors
The callback function of call_rcu() just calls a kfree(), so we
can use kfree_rcu() instead of call_rcu() + callback function.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
net/sched/sch_api.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index 7e4d1cc..53b25b8 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -526,11 +526,6 @@ static struct qdisc_size_table *qdisc_get_stab(struct nlattr *opt,
return stab;
}
-static void stab_kfree_rcu(struct rcu_head *head)
-{
- kfree(container_of(head, struct qdisc_size_table, rcu));
-}
-
void qdisc_put_stab(struct qdisc_size_table *tab)
{
if (!tab)
@@ -538,7 +533,7 @@ void qdisc_put_stab(struct qdisc_size_table *tab)
if (--tab->refcnt == 0) {
list_del(&tab->list);
- call_rcu(&tab->rcu, stab_kfree_rcu);
+ kfree_rcu(tab, rcu);
}
}
EXPORT_SYMBOL(qdisc_put_stab);
^ permalink raw reply related
* Re: [PATCH] net: mv643xx_eth: disable clk on error path in mv643xx_eth_shared_probe()
From: Sergei Shtylyov @ 2019-02-16 8:17 UTC (permalink / raw)
To: Alexey Khoroshilov, Sebastian Hesselbarth, David S. Miller
Cc: netdev, linux-kernel, ldv-project
In-Reply-To: <1550265654-6626-1-git-send-email-khoroshilov@ispras.ru>
On 16.02.2019 0:20, Alexey Khoroshilov wrote:
> If mv643xx_eth_shared_of_probe() fails, mv643xx_eth_shared_probe()
> leaves clk undisabled.
Enabled, that is? :-)
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [net-next] net: crypto set sk to NULL when af_alg_release.
From: maowenan @ 2019-02-16 8:31 UTC (permalink / raw)
To: netdev, davem, xiyou.wangcong, linux-kernel, maowenan
In-Reply-To: <20190215142415.149153-1-maowenan@huawei.com>
who can help review this patch?
thank you.
On 2019/2/15 22:24, Mao Wenan wrote:
> KASAN has found use-after-free in sockfs_setattr.
> The existed commit 6d8c50dcb029 ("socket: close race condition between sock_close()
> and sockfs_setattr()") is to fix this simillar issue, but it seems to ignore
> that crypto module forgets to set the sk to NULL after af_alg_release.
>
> KASAN report details as below:
> BUG: KASAN: use-after-free in sockfs_setattr+0x120/0x150
> Write of size 4 at addr ffff88837b956128 by task syz-executor0/4186
>
> CPU: 2 PID: 4186 Comm: syz-executor0 Not tainted xxx + #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-1ubuntu1 04/01/2014
> Call Trace:
> dump_stack+0xca/0x13e
> print_address_description+0x79/0x330
> ? vprintk_func+0x5e/0xf0
> kasan_report+0x18a/0x2e0
> ? sockfs_setattr+0x120/0x150
> sockfs_setattr+0x120/0x150
> ? sock_register+0x2d0/0x2d0
> notify_change+0x90c/0xd40
> ? chown_common+0x2ef/0x510
> chown_common+0x2ef/0x510
> ? chmod_common+0x3b0/0x3b0
> ? __lock_is_held+0xbc/0x160
> ? __sb_start_write+0x13d/0x2b0
> ? __mnt_want_write+0x19a/0x250
> do_fchownat+0x15c/0x190
> ? __ia32_sys_chmod+0x80/0x80
> ? trace_hardirqs_on_thunk+0x1a/0x1c
> __x64_sys_fchownat+0xbf/0x160
> ? lockdep_hardirqs_on+0x39a/0x5e0
> do_syscall_64+0xc8/0x580
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x462589
> Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89
> f7 48 89 d6 48 89
> ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3
> 48 c7 c1 bc ff ff
> ff f7 d8 64 89 01 48
> RSP: 002b:00007fb4b2c83c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000104
> RAX: ffffffffffffffda RBX: 000000000072bfa0 RCX: 0000000000462589
> RDX: 0000000000000000 RSI: 00000000200000c0 RDI: 0000000000000007
> RBP: 0000000000000005 R08: 0000000000001000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb4b2c846bc
> R13: 00000000004bc733 R14: 00000000006f5138 R15: 00000000ffffffff
>
> Allocated by task 4185:
> kasan_kmalloc+0xa0/0xd0
> __kmalloc+0x14a/0x350
> sk_prot_alloc+0xf6/0x290
> sk_alloc+0x3d/0xc00
> af_alg_accept+0x9e/0x670
> hash_accept+0x4a3/0x650
> __sys_accept4+0x306/0x5c0
> __x64_sys_accept4+0x98/0x100
> do_syscall_64+0xc8/0x580
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 4184:
> __kasan_slab_free+0x12e/0x180
> kfree+0xeb/0x2f0
> __sk_destruct+0x4e6/0x6a0
> sk_destruct+0x48/0x70
> __sk_free+0xa9/0x270
> sk_free+0x2a/0x30
> af_alg_release+0x5c/0x70
> __sock_release+0xd3/0x280
> sock_close+0x1a/0x20
> __fput+0x27f/0x7f0
> task_work_run+0x136/0x1b0
> exit_to_usermode_loop+0x1a7/0x1d0
> do_syscall_64+0x461/0x580
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Syzkaller reproducer:
> r0 = perf_event_open(&(0x7f0000000000)={0x0, 0x70, 0x0, 0x0, 0x0, 0x0,
> 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, @perf_config_ext}, 0x0, 0x0,
> 0xffffffffffffffff, 0x0)
> r1 = socket$alg(0x26, 0x5, 0x0)
> getrusage(0x0, 0x0)
> bind(r1, &(0x7f00000001c0)=@alg={0x26, 'hash\x00', 0x0, 0x0,
> 'sha256-ssse3\x00'}, 0x80)
> r2 = accept(r1, 0x0, 0x0)
> r3 = accept4$unix(r2, 0x0, 0x0, 0x0)
> r4 = dup3(r3, r0, 0x0)
> fchownat(r4, &(0x7f00000000c0)='\x00', 0x0, 0x0, 0x1000)
>
> Fixes: 6d8c50dcb029 ("socket: close race condition between sock_close() and sockfs_setattr()")
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
> ---
> crypto/af_alg.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index 17eb09d222ff..ec78a04eb136 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -122,8 +122,10 @@ static void alg_do_release(const struct af_alg_type *type, void *private)
>
> int af_alg_release(struct socket *sock)
> {
> - if (sock->sk)
> + if (sock->sk) {
> sock_put(sock->sk);
> + sock->sk = NULL;
> + }
> return 0;
> }
> EXPORT_SYMBOL_GPL(af_alg_release);
>
^ permalink raw reply
* [PATCH v2] net: dsa: Implement flow_dissect callback for tag_dsa.
From: Rundong Ge @ 2019-02-16 8:35 UTC (permalink / raw)
To: andrew; +Cc: vivien.didelot, f.fainelli, davem, netdev, linux-kernel, rdong.ge
RPS not work for DSA devices since the 'skb_get_hash'
will always get the invalid hash for dsa tagged packets.
"[PATCH] tag_mtk: add flow_dissect callback to the ops struct"
introduced the flow_dissect callback to get the right hash for
MTK tagged packet. Tag_dsa and tag_edsa also need to implement
the callback.
Signed-off-by: Rundong Ge <rdong.ge@gmail.com>
---
net/dsa/tag_dsa.c | 9 +++++++++
net/dsa/tag_edsa.c | 9 +++++++++
2 files changed, 18 insertions(+)
diff --git a/net/dsa/tag_dsa.c b/net/dsa/tag_dsa.c
index 8b2f92e..67ff3fa 100644
--- a/net/dsa/tag_dsa.c
+++ b/net/dsa/tag_dsa.c
@@ -146,8 +146,17 @@ static struct sk_buff *dsa_rcv(struct sk_buff *skb, struct net_device *dev,
return skb;
}
+static int dsa_tag_flow_dissect(const struct sk_buff *skb, __be16 *proto,
+ int *offset)
+{
+ *offset = 4;
+ *proto = ((__be16 *)skb->data)[1];
+ return 0;
+}
+
const struct dsa_device_ops dsa_netdev_ops = {
.xmit = dsa_xmit,
.rcv = dsa_rcv,
+ .flow_dissect = dsa_tag_flow_dissect,
.overhead = DSA_HLEN,
};
diff --git a/net/dsa/tag_edsa.c b/net/dsa/tag_edsa.c
index f5b87ee..234585e 100644
--- a/net/dsa/tag_edsa.c
+++ b/net/dsa/tag_edsa.c
@@ -165,8 +165,17 @@ static struct sk_buff *edsa_rcv(struct sk_buff *skb, struct net_device *dev,
return skb;
}
+static int edsa_tag_flow_dissect(const struct sk_buff *skb, __be16 *proto,
+ int *offset)
+{
+ *offset = 8;
+ *proto = ((__be16 *)skb->data)[3];
+ return 0;
+}
+
const struct dsa_device_ops edsa_netdev_ops = {
.xmit = edsa_xmit,
.rcv = edsa_rcv,
+ .flow_dissect = edsa_tag_flow_dissect,
.overhead = EDSA_HLEN,
};
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH RFC] net: bridge: don't flood known multicast traffic when snooping is enabled
From: Nikolay Aleksandrov @ 2019-02-16 8:35 UTC (permalink / raw)
To: Linus Lüssing; +Cc: netdev, roopa, wkok, anuradhak, bridge, davem, stephen
In-Reply-To: <479a1acf-c7f3-4e6f-4246-e1583e98d356@cumulusnetworks.com>
On 16/02/2019 10:05, Nikolay Aleksandrov wrote:
> On 15/02/2019 19:13, Linus Lüssing wrote:
>> On Fri, Feb 15, 2019 at 03:04:27PM +0200, Nikolay Aleksandrov wrote:
>>> Every user would expect to have traffic forwarded only to the configured
>>> mdb destination when snooping is enabled, instead now to get that one
>>> needs to enable both snooping and querier. Enabling querier on all
>>> switches could be problematic and is not a good solution,
>>
>> There is no need to set the querier on all snooping switches.
>> br_multicast_querier_exists() checks if a querier exists on the
>> link in general, not if this particular host/bridge is a querier.
>>
>
> We need a generic solution for the case of existing mdst and no querier.
> More below.
>
>>
>>> for example as summarized by our multicast experts:
>>> "every switch would send an IGMP query
>>
>> What? RFC3810, section 7.1 says:
>>
>> "If it is the case, a querier election mechanism (described in
>> section 7.6.2) is used to elect a single multicast router to be
>> in Querier state. [...] Nevertheless, it is only the [elected] Querier
>> that sends periodical or triggered query messages on the subnet."
>>>> for any random multicast traffic it
>>> received across the entire domain and it would send it forever as long as a
>>> host exists wanting that stream even if it has no downstream/directly
>>> connected receivers"
>>
>
> This was taken out of context and it's my bad, I think everyone is aware
> of the election process, please nevermind the above statement.
>
> [snip]>
>>
>> Have you done some tests with this change yet, Nikolay?
>>
>
> You've raised good questions, IPv6 indeed needs more work - we'll have to flood
> link-local packets etc. but I wanted to have a discussion about no querier/existing mdst.
> To simplify we can modify the patch and have traffic forwarded to the proper ports when an
> mdst exists and there is no querier for both unsolicited report and user-added entry.
To add a bit more:
"- no querier exists on the link
- one port gets an unsolicited MLD report, i.e. because a host has just
started to listen to a particular multicast address
=> will only this port receive multicast traffic? what happens to
other ports that have listeners for the same multicast group?"
Correct, only the interested ports (where reports have been seen or the user has
added them) will get the traffic. We could also consider having this only
for user-added mdsts, I'll have to think more about that.
> We can keep the current behaviour for unknown traffic with and without querier.
> This would align it closer to what other vendors currently do as well IIRC.
> What do you think ?
>
> Thanks,
> Nik
>
^ permalink raw reply
* Re: [PATCH v2] net: dsa: Implement flow_dissect callback for tag_dsa.
From: Rundong Ge @ 2019-02-16 8:38 UTC (permalink / raw)
To: Andrew Lunn; +Cc: vivien.didelot, Florian Fainelli, davem, netdev, linux-kernel
In-Reply-To: <20190216083524.860-1-rdong.ge@gmail.com>
Hi Andrew
I have tested the L3 forwarding throughput performance of my box (with
an intel 4-core processor and each core’s frequency is 2.20GHz).
In my test scenario, I generated 200 UDP flows (frame size is 64
bytes) with different src/dst pairs from eth1 to eth0. Eth1 is a slave
DSA device from mv88e6190x, eth0 is an intel NIC. Then get the max fps
with no frame losing.
The max fps with RPS working is 400235fps, frames are hashed to four
cores’ backlog.
And the max fps without RPS is 199686fps.
Rundong
Rundong Ge <rdong.ge@gmail.com> 于2019年2月16日周六 下午4:35写道：
>
> RPS not work for DSA devices since the 'skb_get_hash'
> will always get the invalid hash for dsa tagged packets.
>
> "[PATCH] tag_mtk: add flow_dissect callback to the ops struct"
> introduced the flow_dissect callback to get the right hash for
> MTK tagged packet. Tag_dsa and tag_edsa also need to implement
> the callback.
>
> Signed-off-by: Rundong Ge <rdong.ge@gmail.com>
> ---
> net/dsa/tag_dsa.c | 9 +++++++++
> net/dsa/tag_edsa.c | 9 +++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/net/dsa/tag_dsa.c b/net/dsa/tag_dsa.c
> index 8b2f92e..67ff3fa 100644
> --- a/net/dsa/tag_dsa.c
> +++ b/net/dsa/tag_dsa.c
> @@ -146,8 +146,17 @@ static struct sk_buff *dsa_rcv(struct sk_buff *skb, struct net_device *dev,
> return skb;
> }
>
> +static int dsa_tag_flow_dissect(const struct sk_buff *skb, __be16 *proto,
> + int *offset)
> +{
> + *offset = 4;
> + *proto = ((__be16 *)skb->data)[1];
> + return 0;
> +}
> +
> const struct dsa_device_ops dsa_netdev_ops = {
> .xmit = dsa_xmit,
> .rcv = dsa_rcv,
> + .flow_dissect = dsa_tag_flow_dissect,
> .overhead = DSA_HLEN,
> };
> diff --git a/net/dsa/tag_edsa.c b/net/dsa/tag_edsa.c
> index f5b87ee..234585e 100644
> --- a/net/dsa/tag_edsa.c
> +++ b/net/dsa/tag_edsa.c
> @@ -165,8 +165,17 @@ static struct sk_buff *edsa_rcv(struct sk_buff *skb, struct net_device *dev,
> return skb;
> }
>
> +static int edsa_tag_flow_dissect(const struct sk_buff *skb, __be16 *proto,
> + int *offset)
> +{
> + *offset = 8;
> + *proto = ((__be16 *)skb->data)[3];
> + return 0;
> +}
> +
> const struct dsa_device_ops edsa_netdev_ops = {
> .xmit = edsa_xmit,
> .rcv = edsa_rcv,
> + .flow_dissect = edsa_tag_flow_dissect,
> .overhead = EDSA_HLEN,
> };
> --
> 1.8.3.1
>
^ permalink raw reply
* [PATCH] r8152: Add support for MAC address pass through on RTL8153-BD
From: David Chen @ 2019-02-16 9:16 UTC (permalink / raw)
To: linux-usb, netdev, linux-kernel
Cc: davem, hayeswang, mario.limonciello, bigeasy, edumazet, jslaby,
f.fainelli, david.chen7, kai.heng.feng, zhongjiang
From: David Chen <david.chen7@dell.com>
RTL8153-BD is used in Dell DA300 type-C dongle.
It should be added to the whitelist of devices to activate MAC address
pass through.
Per confirming with Realtek all devices containing RTL8153-BD should
activate MAC pass through and there won't use pass through bit on efuse
like in RTL8153-AD.
Signed-off-by: David Chen <david.chen7@dell.com>
---
drivers/net/usb/r8152.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 60dd1ec1665f..ada6baf8847a 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -557,6 +557,7 @@ enum spd_duplex {
/* MAC PASSTHRU */
#define AD_MASK 0xfee0
#define BND_MASK 0x0004
+#define BD_MASK 0x0001
#define EFUSE 0xcfdb
#define PASS_THRU_MASK 0x1
@@ -1176,9 +1177,9 @@ static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
return -ENODEV;
}
} else {
- /* test for RTL8153-BND */
+ /* test for RTL8153-BND and RTL8153-BD */
ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_MISC_1);
- if ((ocp_data & BND_MASK) == 0) {
+ if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK)) {
netif_dbg(tp, probe, tp->netdev,
"Invalid variant for MAC pass through\n");
return -ENODEV;
--
2.19.1
^ permalink raw reply related
* [PATCH net-next] r8169: remove unneeded mmiowb barriers
From: Heiner Kallweit @ 2019-02-16 9:20 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
writex() has implicit barriers, that's what makes it different from
writex_relaxed(). Therefore these calls to mmiowb() can be removed.
This patch was recently reverted due to a dependency with another
problematic patch. But because it didn't contribute to the problem
it was rebased and can be resubmitted.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 548fe260b..3cca2ffb2 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1288,13 +1288,11 @@ static u8 rtl8168d_efuse_read(struct rtl8169_private *tp, int reg_addr)
static void rtl_ack_events(struct rtl8169_private *tp, u16 bits)
{
RTL_W16(tp, IntrStatus, bits);
- mmiowb();
}
static void rtl_irq_disable(struct rtl8169_private *tp)
{
RTL_W16(tp, IntrMask, 0);
- mmiowb();
}
#define RTL_EVENT_NAPI_RX (RxOK | RxErr)
@@ -6251,8 +6249,6 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
RTL_W8(tp, TxPoll, NPQ);
- mmiowb();
-
if (!rtl_tx_slots_avail(tp, MAX_SKB_FRAGS)) {
/* Avoid wrongly optimistic queue wake-up: rtl_tx thread must
* not miss a ring update when it notices a stopped queue.
@@ -6597,9 +6593,7 @@ static int rtl8169_poll(struct napi_struct *napi, int budget)
if (work_done < budget) {
napi_complete_done(napi, work_done);
-
rtl_irq_enable(tp);
- mmiowb();
}
return work_done;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next] cfg80211: pmsr: use eth_broadcast_addr() to assign broadcast address
From: Mao Wenan @ 2019-02-16 9:47 UTC (permalink / raw)
To: johannes, linux-wireless, kernel-janitors, netdev
This patch is to use eth_broadcast_addr() to assign broadcast address
insetad of memset().
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
net/wireless/pmsr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/pmsr.c b/net/wireless/pmsr.c
index de9286703280..21139b82749f 100644
--- a/net/wireless/pmsr.c
+++ b/net/wireless/pmsr.c
@@ -258,7 +258,7 @@ int nl80211_pmsr_start(struct sk_buff *skb, struct genl_info *info)
} else {
memcpy(req->mac_addr, nla_data(info->attrs[NL80211_ATTR_MAC]),
ETH_ALEN);
- memset(req->mac_addr_mask, 0xff, ETH_ALEN);
+ eth_broadcast_addr(req->mac_addr_mask);
}
idx = 0;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next] netfilter: ipt_CLUSTERIP: make symbol 'cip_netdev_notifier' static
From: Pablo Neira Ayuso @ 2019-02-16 9:44 UTC (permalink / raw)
To: Wei Yongjun
Cc: Jozsef Kadlecsik, Florian Westphal, Alexey Kuznetsov,
Hideaki YOSHIFUJI, Taehee Yoo, netfilter-devel, coreteam, netdev,
kernel-janitors
In-Reply-To: <20190216081606.91596-1-weiyongjun1@huawei.com>
On Sat, Feb 16, 2019 at 08:16:06AM +0000, Wei Yongjun wrote:
> Fixes the following sparse warnings:
>
> net/ipv4/netfilter/ipt_CLUSTERIP.c:867:23: warning:
> symbol 'cip_netdev_notifier' was not declared. Should it be static?
Applied, thanks.
^ permalink raw reply
* [PATCH net-next] liquidio: using NULL instead of plain integer
From: YueHaibing @ 2019-02-16 9:53 UTC (permalink / raw)
To: davem, dchickles, sburla, fmanlunas; +Cc: linux-kernel, netdev, YueHaibing
Fix following warning:
drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c:1453:35: warning: Using plain integer as NULL pointer
drivers/net/ethernet/cavium/liquidio/lio_main.c:2910:23: warning: Using plain integer as NULL pointer
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c | 2 +-
drivers/net/ethernet/cavium/liquidio/lio_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
index 9f4f3c1d..43d11c3 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
@@ -1450,7 +1450,7 @@ void cn23xx_tell_vf_its_macaddr_changed(struct octeon_device *oct, int vfidx,
mbox_cmd.recv_len = 0;
mbox_cmd.recv_status = 0;
mbox_cmd.fn = NULL;
- mbox_cmd.fn_arg = 0;
+ mbox_cmd.fn_arg = NULL;
ether_addr_copy(mbox_cmd.msg.s.params, mac);
mbox_cmd.q_no = vfidx * oct->sriov_info.rings_per_vf;
octeon_mbox_write(oct, &mbox_cmd);
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index e97e675..9b7819f 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -2907,7 +2907,7 @@ static int liquidio_set_vf_spoofchk(struct net_device *netdev, int vfidx,
nctrl.ncmd.s.param2 = enable;
nctrl.ncmd.s.more = 0;
nctrl.iq_no = lio->linfo.txpciq[0].s.q_no;
- nctrl.cb_fn = 0;
+ nctrl.cb_fn = NULL;
retval = octnet_send_nic_ctrl_pkt(oct, &nctrl);
--
2.7.0
^ permalink raw reply related
* INFO: task hung in addrconf_dad_work
From: syzbot @ 2019-02-16 10:20 UTC (permalink / raw)
To: ast, christian, daniel, davem, dsahern, hawk, idosch,
jakub.kicinski, john.fastabend, kafai, ktkhai, linux-kernel,
netdev, petrm, roopa, songliubraving, syzkaller-bugs, xdp-newbies,
yhs
Hello,
syzbot found the following crash on:
HEAD commit: 5ded5871030e Merge tag 'scsi-fixes' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1577228f400000
kernel config: https://syzkaller.appspot.com/x/.config?x=ee434566c893c7b1
dashboard link: https://syzkaller.appspot.com/bug?extid=f4290c15a8ab6dee87c9
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10ee52d4c00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1073879cc00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+f4290c15a8ab6dee87c9@syzkaller.appspotmail.com
INFO: task kworker/0:1:12 blocked for more than 140 seconds.
Not tainted 5.0.0-rc6+ #73
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/0:1 D26560 12 2 0x80000000
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
context_switch kernel/sched/core.c:2844 [inline]
__schedule+0x817/0x1cc0 kernel/sched/core.c:3485
schedule+0x92/0x180 kernel/sched/core.c:3529
schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:3587
__mutex_lock_common kernel/locking/mutex.c:1002 [inline]
__mutex_lock+0x726/0x1310 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
rtnl_lock+0x17/0x20 net/core/rtnetlink.c:77
addrconf_dad_work+0xad/0x1150 net/ipv6/addrconf.c:3995
process_one_work+0x98e/0x1790 kernel/workqueue.c:2173
worker_thread+0x98/0xe40 kernel/workqueue.c:2319
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
INFO: task kworker/1:1:22 blocked for more than 140 seconds.
Not tainted 5.0.0-rc6+ #73
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/1:1 D26848 22 2 0x80000000
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
context_switch kernel/sched/core.c:2844 [inline]
__schedule+0x817/0x1cc0 kernel/sched/core.c:3485
schedule+0x92/0x180 kernel/sched/core.c:3529
schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:3587
__mutex_lock_common kernel/locking/mutex.c:1002 [inline]
__mutex_lock+0x726/0x1310 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
rtnl_lock+0x17/0x20 net/core/rtnetlink.c:77
addrconf_dad_work+0xad/0x1150 net/ipv6/addrconf.c:3995
process_one_work+0x98e/0x1790 kernel/workqueue.c:2173
worker_thread+0x98/0xe40 kernel/workqueue.c:2319
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Showing all locks held in the system:
3 locks held by kworker/0:1/12:
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
__write_once_size include/linux/compiler.h:220 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
atomic64_set include/asm-generic/atomic-instrumented.h:40 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
atomic_long_set include/asm-generic/atomic-long.h:59 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
set_work_data kernel/workqueue.c:617 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
process_one_work+0x87e/0x1790 kernel/workqueue.c:2144
#1: 00000000ba501015 ((work_completion)(&(&ifa->dad_work)->work)){+.+.},
at: process_one_work+0x8b4/0x1790 kernel/workqueue.c:2148
#2: 000000000a023ce4 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:77
3 locks held by kworker/1:1/22:
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
__write_once_size include/linux/compiler.h:220 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
atomic64_set include/asm-generic/atomic-instrumented.h:40 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
atomic_long_set include/asm-generic/atomic-long.h:59 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
set_work_data kernel/workqueue.c:617 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
#0: 00000000c092f744 ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
process_one_work+0x87e/0x1790 kernel/workqueue.c:2144
#1: 00000000609e3f2e ((work_completion)(&(&ifa->dad_work)->work)){+.+.},
at: process_one_work+0x8b4/0x1790 kernel/workqueue.c:2148
#2: 000000000a023ce4 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:77
1 lock held by khungtaskd/1039:
#0: 000000009a681c98 (rcu_read_lock){....}, at:
debug_show_all_locks+0x5f/0x27e kernel/locking/lockdep.c:4389
1 lock held by rsyslogd/7932:
#0: 000000000ae60368 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0xee/0x110
fs/file.c:795
2 locks held by getty/8054:
#0: 00000000330eb6bd (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000115a4ff9 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/8055:
#0: 000000001f90753f (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 000000001e27037e (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/8056:
#0: 0000000027f8ba41 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000a0356b01 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/8057:
#0: 000000009cf2ea94 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 0000000097e38bce (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/8058:
#0: 000000006dd48e75 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000a75b841a (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/8059:
#0: 0000000020112132 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000c3504044 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
2 locks held by getty/8060:
#0: 000000001510234f (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000e70220db (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2154
1 lock held by syz-executor112/8443:
=============================================
NMI backtrace for cpu 1
CPU: 1 PID: 1039 Comm: khungtaskd Not tainted 5.0.0-rc6+ #73
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
nmi_cpu_backtrace.cold+0x63/0xa4 lib/nmi_backtrace.c:101
nmi_trigger_cpumask_backtrace+0x1be/0x236 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_all_cpu_backtrace include/linux/nmi.h:146 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:203 [inline]
watchdog+0x9df/0xee0 kernel/hung_task.c:287
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Sending NMI from CPU 1 to CPUs 0:
INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 1.262
msecs
NMI backtrace for cpu 0
CPU: 0 PID: 8443 Comm: syz-executor112 Not tainted 5.0.0-rc6+ #73
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:preempt_count_add+0xf8/0x1b0 kernel/sched/core.c:3210
Code: 11 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02
00 0f 85 ab 00 00 00 49 89 9c 24 b0 11 00 00 5b 41 5c 5d <c3> 48 8b 45 00
48 8b 58 08 48 89 df e8 27 e7 09 00 85 c0 74 b3 48
RSP: 0018:ffff88809e13f190 EFLAGS: 00000046
RAX: dffffc0000000000 RBX: 0000000000000286 RCX: 0000000000000000
RDX: 1ffff1100f1efe66 RSI: 0000000000000000 RDI: ffff888078f7f330
RBP: ffff88809e13f1a8 R08: ffff888078f7e180 R09: ffffed1015d05bd0
R10: ffffed1015d05bcf R11: ffff8880ae82de7b R12: ffffffff8a648b08
R13: 0000000000000086 R14: ffffffff8a648b08 R15: 00000000004012c0
FS: 00000000019f3940(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffff600400 CR3: 00000000a1211000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__debug_check_no_obj_freed lib/debugobjects.c:776 [inline]
debug_check_no_obj_freed+0xbe/0x464 lib/debugobjects.c:817
kfree+0xbd/0x230 mm/slab.c:3805
skb_free_head+0x93/0xb0 net/core/skbuff.c:553
pskb_expand_head+0x2ba/0xdd0 net/core/skbuff.c:1498
netlink_trim+0x215/0x270 net/netlink/af_netlink.c:1292
netlink_unicast+0xbf/0x720 net/netlink/af_netlink.c:1326
rtnetlink_send+0xf0/0x110 net/core/rtnetlink.c:721
tcf_add_notify net/sched/act_api.c:1325 [inline]
tcf_action_add+0x243/0x370 net/sched/act_api.c:1344
tc_ctl_action+0x3b6/0x4bd net/sched/act_api.c:1392
rtnetlink_rcv_msg+0x465/0xb00 net/core/rtnetlink.c:5130
netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5148
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2114
__sys_sendmsg+0x105/0x1d0 net/socket.c:2152
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg net/socket.c:2159 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45b129
Code: e8 3c 0a 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 5b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffc05c7adc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 000000000045b129
RDX: 00000000000000c4 RSI: 0000000020000300 RDI: 0000000000000003
RBP: 0000000000000000 R08: 00000000000003e8 R09: 00000000000003e8
R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000162
R13: 000000000041bda0 R14: 0000000000000000 R15: 0000000000000000
---
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.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* -Wimplicit-fallthrough not working with ccache
From: Kalle Valo @ 2019-02-16 11:21 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: netdev, linux-wireless, linux-kernel, ath10k, David S. Miller,
linux-kbuild
In-Reply-To: <20180613114059.DAC95601D2@smtp.codeaurora.org>
(replying to an old thread but renaming it)
Kalle Valo <kvalo@codeaurora.org> writes:
> "Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
>
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> Notice that in this particular case, I replaced "pass through" with
>> a proper "fall through" comment, which is what GCC is expecting
>> to find.
>>
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>
> Patch applied to ath-next branch of ath.git, thanks.
>
> f1d270ae10ff ath10k: htt_tx: mark expected switch fall-throughs
Gustavo, I enabled W=1 on my ath10k build checks and it took me a while
to figure out why GCC was warning about fall through annotations missing
even I knew you had fixed them. Finally I figured out that the reason
was ccache, which I need because I work with different branches and need
to recompile the kernel quite often.
If the plan is to enable -Wimplicit-fallthrough by default in the kernel
IMHO this might become an issue, as otherwise people using ccache start
seeing lots of invalid warnings. Apparently CCACHE_COMMENTS=1 will fix
that but my version of ccache doesn't support it, and how would everyone
learn that trick anyway? Or maybe CCACHE_COMMENTS can enabled through
kernel Makefile?
--
Kalle Valo
^ permalink raw reply
* phy speed setting issue: e1000: Add support for the CE4100 reference platform
From: Colin Ian King @ 2019-02-16 14:26 UTC (permalink / raw)
To: Dirk Brandewie, Jeff Pieper, Jeff Kirsher
Cc: David S. Miller, netdev, linux-kernel@vger.kernel.org
Hi,
Static analysis from CoverityScan has detected an issue with the speed
setup with the control setting in the e1000 driver.
Function e1000_config_mac_to_phy in
/drivers/net/ethernet/intel/e1000/e1000_hw.c, CoverityScan reports:
CID 140032 (#1 of 1): Operands don't affect result
(CONSTANT_EXPRESSION_RESULT)
result_independent_of_operands: phy_data & 0x200000 is always 0
regardless of the values of its operands. This occurs as the logical
operand of if.
1936 if (phy_data & RTL_PHY_CTRL_SPD_100)
1937 ctrl |= E1000_CTRL_SPD_100;
1938 else
1939 ctrl |= E1000_CTRL_SPD_10;
phy_data is a u16 however the 100 mbit speed bitmask is 0x200000, hence
the bitwise with phy_data will always result in zero, and so the ctrl is
never set to E1000_CTRL_SPD_100.
I'm not familiar with this hardware, so I'm not sure what appropriate
mask should be.
Issue was introduced with commit: 5377a4160bb6 ("e1000: Add support for
the CE4100 reference platform")
Colin
^ permalink raw reply
* Re: [PATCH v2] net: dsa: Implement flow_dissect callback for tag_dsa.
From: Andrew Lunn @ 2019-02-16 15:35 UTC (permalink / raw)
To: Rundong Ge; +Cc: vivien.didelot, Florian Fainelli, davem, netdev, linux-kernel
In-Reply-To: <CAN1Lvyqo4K3OJEO-RAnp03tM5SgBr3ZK=NTCtKOc+YTymjw8CA@mail.gmail.com>
On Sat, Feb 16, 2019 at 04:38:25PM +0800, Rundong Ge wrote:
> Hi Andrew
>
> I have tested the L3 forwarding throughput performance of my box (with
> an intel 4-core processor and each core’s frequency is 2.20GHz).
> In my test scenario, I generated 200 UDP flows (frame size is 64
> bytes) with different src/dst pairs from eth1 to eth0. Eth1 is a slave
> DSA device from mv88e6190x, eth0 is an intel NIC. Then get the max fps
> with no frame losing.
>
> The max fps with RPS working is 400235fps, frames are hashed to four
> cores’ backlog.
> And the max fps without RPS is 199686fps.
Nice numbers, thanks.
Andrew
^ permalink raw reply
* Re: [PATCH v2] net: dsa: Implement flow_dissect callback for tag_dsa.
From: Andrew Lunn @ 2019-02-16 15:42 UTC (permalink / raw)
To: Rundong Ge; +Cc: vivien.didelot, f.fainelli, davem, netdev, linux-kernel
In-Reply-To: <20190216083524.860-1-rdong.ge@gmail.com>
On Sat, Feb 16, 2019 at 08:35:24AM +0000, Rundong Ge wrote:
> RPS not work for DSA devices since the 'skb_get_hash'
> will always get the invalid hash for dsa tagged packets.
>
> "[PATCH] tag_mtk: add flow_dissect callback to the ops struct"
> introduced the flow_dissect callback to get the right hash for
> MTK tagged packet. Tag_dsa and tag_edsa also need to implement
> the callback.
>
> Signed-off-by: Rundong Ge <rdong.ge@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: phy: add helpers for handling C45 10GBT AN register values
From: Andrew Lunn @ 2019-02-16 16:00 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <5c217a09-dac8-d8db-3a38-c9a621ae55a6@gmail.com>
On Fri, Feb 15, 2019 at 09:57:49PM +0100, Heiner Kallweit wrote:
> Similar to the existing helpers for the Clause 22 registers add helpers
> to deal with converting Clause 45 advertisement registers to / from
> link mode bitmaps.
>
> Note that these helpers are defined in linux/mdio.h, not like the
> Clause 22 helpers in linux/mii.h. Reason is that the Clause 45 register
> constants are defined in uapi/linux/mdio.h. And uapi/linux/mdio.h
> includes linux/mii.h before defining the C45 register constants.
Hi Heiner
You add three helpers, but the followup patch only uses one of them.
Maybe you should wait until you have real uses of the other two?
Or just add the one helper.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: phy: add helpers for handling C45 10GBT AN register values
From: Heiner Kallweit @ 2019-02-16 16:07 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <20190216160053.GP5699@lunn.ch>
On 16.02.2019 17:00, Andrew Lunn wrote:
> On Fri, Feb 15, 2019 at 09:57:49PM +0100, Heiner Kallweit wrote:
>> Similar to the existing helpers for the Clause 22 registers add helpers
>> to deal with converting Clause 45 advertisement registers to / from
>> link mode bitmaps.
>>
>> Note that these helpers are defined in linux/mdio.h, not like the
>> Clause 22 helpers in linux/mii.h. Reason is that the Clause 45 register
>> constants are defined in uapi/linux/mdio.h. And uapi/linux/mdio.h
>> includes linux/mii.h before defining the C45 register constants.
>
> Hi Heiner
>
> You add three helpers, but the followup patch only uses one of them.
> Maybe you should wait until you have real uses of the other two?
> Or just add the one helper.
>
Ah, right. I created all helpers but at least one user isn't ready yet.
I'll resend the series with just the helper being used now.
> Andrew
>
Heiner
^ permalink raw reply
* [BUG] [FIX] net: dsa: oops in br_vlan_enabled
From: Frank Wunderlich @ 2019-02-16 16:22 UTC (permalink / raw)
To: netdev
Hi,
i've found an oops in 4.19.23/10, seems to be fixed anyhow in 5.0 (also works in 4.14.101)
root@bpi-r2:~# ip link add link lan0 name lan0.5 type vlan id 5
root@bpi-r2:~# ip addr add 192.168.5.200/24 brd 192.168.5.255 dev lan0.5
root@bpi-r2:~# ip link set dev lan0 up
root@bpi-r2:~# ip link set dev lan0.5 up
12: lan0.5@lan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000
link/ether 02:02:02:02:02:02 brd ff:ff:ff:ff:ff:ff
inet 192.168.5.200/24 brd 192.168.5.255 scope global lan0.5
valid_lft forever preferred_lft forever
root@bpi-r2:~# brctl addbr bridge_name
root@bpi-r2:~# brctl addif bridge_name lan0.5
[ 352.057128] bridge_name: port 1(lan0.5) entered blocking state
[ 352.063065] bridge_name: port 1(lan0.5) entered disabled state
[ 352.069181] device lan0.5 entered promiscuous mode
[ 352.074018] device lan0 entered promiscuous mode
[ 352.078906] Unable to handle kernel NULL pointer dereference at virtual address 00000558
...
[ 352.493085] [<bf0fde88>] (br_vlan_enabled [bridge]) from [<bf12c234>] (dsa_port_vlan_add+0x60/0xbc [dsa_core])
[ 352.503050] [<bf12c234>] (dsa_port_vlan_add [dsa_core]) from [<bf12cb64>] (dsa_slave_port_obj_add+0x4c/0x50 [dsa_core])
[ 352.513776] [<bf12cb64>] (dsa_slave_port_obj_add [dsa_core]) from [<c0b4e2d4>] (__switchdev_port_obj_add+0x50/0xc4)
[ 352.524138] [<c0b4e2d4>] (__switchdev_port_obj_add) from [<c0b4e324>] (__switchdev_port_obj_add+0xa0/0xc4)
[ 352.533721] [<c0b4e324>] (__switchdev_port_obj_add) from [<c0b4e3a8>] (switchdev_port_obj_add_now+0x60/0x130)
[ 352.543562] [<c0b4e3a8>] (switchdev_port_obj_add_now) from [<c0b4e7e4>] (switchdev_port_obj_add+0x44/0x190)
[ 352.553284] [<c0b4e7e4>] (switchdev_port_obj_add) from [<bf1013d0>] (br_switchdev_port_vlan_add+0x60/0x7c [bridge])
[ 352.563733] [<bf1013d0>] (br_switchdev_port_vlan_add [bridge]) from [<bf0ff250>] (__vlan_add+0xb0/0x620 [bridge])
[ 352.574007] [<bf0ff250>] (__vlan_add [bridge]) from [<bf0ffd04>] (nbp_vlan_add+0xc4/0x150 [bridge])
[ 352.583073] [<bf0ffd04>] (nbp_vlan_add [bridge]) from [<bf0ffec4>] (nbp_vlan_init+0x134/0x164 [bridge])
[ 352.592482] [<bf0ffec4>] (nbp_vlan_init [bridge]) from [<bf0edd4c>] (br_add_if+0x40c/0x5fc [bridge])
[ 352.601632] [<bf0edd4c>] (br_add_if [bridge]) from [<bf0eeb14>] (add_del_if+0x6c/0x80 [bridge])
[ 352.610351] [<bf0eeb14>] (add_del_if [bridge]) from [<bf0ef5b0>] (br_dev_ioctl+0x7c/0x9c [bridge])
[ 352.619290] [<bf0ef5b0>] (br_dev_ioctl [bridge]) from [<c09583d4>] (dev_ifsioc+0x184/0x324)
[ 352.627582] [<c09583d4>] (dev_ifsioc) from [<c09589e8>] (dev_ioctl+0x32c/0x5cc)
[ 352.634837] [<c09589e8>] (dev_ioctl) from [<c090913c>] (sock_ioctl+0x3bc/0x580)
since my 4.19.23 kernel is modified a bit i tried with 4.19.10 without my net modifications and it is still reproducable with steps above (create a vlan on dsa-user-port and then use it in a bridge)
i fixed it with these changes:
diff --git a/net/dsa/port.c b/net/dsa/port.c
index ed0595459df1..962887752ae8 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -255,8 +255,9 @@ int dsa_port_vlan_add(struct dsa_port *dp,
if (netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
- if (br_vlan_enabled(dp->bridge_dev))
- return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, &info);
+ printk(KERN_ALERT "DEBUG: Passed %s %d 0x%x \n",__FUNCTION__,__LINE__,(unsigned int)dp->bridge_dev);
+ if (!dp->bridge_dev || br_vlan_enabled(dp->bridge_dev))
+ return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info);
return 0;
}
@@ -273,7 +274,7 @@ int dsa_port_vlan_del(struct dsa_port *dp,
if (netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
- if (br_vlan_enabled(dp->bridge_dev))
+ if (!dp->bridge_dev || br_vlan_enabled(dp->bridge_dev))
return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info);
return 0;
i've found in a Patch from florian/vivien: https://www.mail-archive.com/netdev@vger.kernel.org/msg281415.html
Strange that 5.0-rc1 does not crash,because these 2 code-sections are unchanged: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/dsa/port.c#n255 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_vlan.c#n788
maybe you know why only 4.19 is affected...
regards Frank
^ 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