* KASAN: use-after-free Read in bpf_tcp_close
From: syzbot @ 2018-05-26 8:54 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 3fb48d881dbe Merge branch 'bpf-fib-mtu-check'
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15fc1977800000
kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
dashboard link: https://syzkaller.appspot.com/bug?extid=fce8f2462c403d02af98
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1310c857800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17de7177800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+fce8f2462c403d02af98@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in hlist_del_rcu include/linux/rculist.h:427
[inline]
BUG: KASAN: use-after-free in bpf_tcp_close+0xd7f/0xf80
kernel/bpf/sockmap.c:271
Read of size 8 at addr ffff8801c884cf90 by task syz-executor330/11778
CPU: 1 PID: 11778 Comm: syz-executor330 Not tainted 4.17.0-rc4+ #18
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+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
hlist_del_rcu include/linux/rculist.h:427 [inline]
bpf_tcp_close+0xd7f/0xf80 kernel/bpf/sockmap.c:271
inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
sock_release+0x96/0x1b0 net/socket.c:594
sock_close+0x16/0x20 net/socket.c:1149
__fput+0x34d/0x890 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1e4/0x290 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x1aee/0x2730 kernel/exit.c:865
do_group_exit+0x16f/0x430 kernel/exit.c:968
get_signal+0x886/0x1960 kernel/signal.c:2469
do_signal+0x98/0x2040 arch/x86/kernel/signal.c:810
exit_to_usermode_loop+0x28a/0x310 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445ed9
RSP: 002b:00007f0078c0adb8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 00000000006dbc24 RCX: 0000000000445ed9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000006dbc24
RBP: 00000000006dbc20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffcd147dbef R14: 00007f0078c0b9c0 R15: 0000000000000007
Allocated by task 11787:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/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:554 [inline]
alloc_sock_hash_elem kernel/bpf/sockmap.c:2114 [inline]
sock_hash_ctx_update_elem.isra.23+0xa57/0x1560 kernel/bpf/sockmap.c:2245
sock_hash_update_elem+0x14f/0x2d0 kernel/bpf/sockmap.c:2303
map_update_elem+0x5c4/0xc90 kernel/bpf/syscall.c:760
__do_sys_bpf kernel/bpf/syscall.c:2134 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2105 [inline]
__x64_sys_bpf+0x32a/0x4f0 kernel/bpf/syscall.c:2105
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 8998:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x260 mm/slab.c:3813
sock_hash_free+0x24e/0x6e0 kernel/bpf/sockmap.c:2093
bpf_map_free_deferred+0xba/0xf0 kernel/bpf/syscall.c:259
process_one_work+0xc1e/0x1b50 kernel/workqueue.c:2145
worker_thread+0x1cc/0x1440 kernel/workqueue.c:2279
kthread+0x345/0x410 kernel/kthread.c:238
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
The buggy address belongs to the object at ffff8801c884cf80
which belongs to the cache kmalloc-64 of size 64
The buggy address is located 16 bytes inside of
64-byte region [ffff8801c884cf80, ffff8801c884cfc0)
The buggy address belongs to the page:
page:ffffea0007221300 count:1 mapcount:0 mapping:ffff8801c884c000 index:0x0
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffff8801c884c000 0000000000000000 0000000100000020
raw: ffffea00072e08e0 ffffea0006e99660 ffff8801da800340 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801c884ce80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff8801c884cf00: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
> ffff8801c884cf80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ffff8801c884d000: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
ffff8801c884d080: 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.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* general protection fault in bpf_tcp_close
From: syzbot @ 2018-05-26 9:13 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: fd0bfa8d6e04 Merge branch 'bpf-af-xdp-cleanups'
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11da9427800000
kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
dashboard link: https://syzkaller.appspot.com/bug?extid=0ce137753c78f7b6acc1
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+0ce137753c78f7b6acc1@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] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 12139 Comm: syz-executor2 Not tainted 4.17.0-rc4+ #17
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__hlist_del include/linux/list.h:649 [inline]
RIP: 0010:hlist_del_rcu include/linux/rculist.h:427 [inline]
RIP: 0010:bpf_tcp_close+0x7d2/0xf80 kernel/bpf/sockmap.c:271
RSP: 0018:ffff8801a8f8ef70 EFLAGS: 00010a02
RAX: ffffed00351f1dfd RBX: dffffc0000000000 RCX: dead000000000200
RDX: 0000000000000000 RSI: 1bd5a00000000040 RDI: ffff8801cb710910
RBP: ffff8801a8f8f110 R08: ffffed003350ac9d R09: ffffed003350ac9c
R10: ffffed003350ac9c R11: ffff88019a8564e3 R12: ffff8801cb710380
R13: ffff8801b17ea6e0 R14: ffff8801cb710398 R15: ffff8801cb710900
FS: 00007f9890c43700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fde1a668000 CR3: 000000019dca2000 CR4: 00000000001406f0
DR0: 00000000200001c0 DR1: 00000000200001c0 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Call Trace:
inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
sock_release+0x96/0x1b0 net/socket.c:594
sock_close+0x16/0x20 net/socket.c:1149
__fput+0x34d/0x890 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1e4/0x290 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x1aee/0x2730 kernel/exit.c:865
do_group_exit+0x16f/0x430 kernel/exit.c:968
get_signal+0x886/0x1960 kernel/signal.c:2469
do_signal+0x98/0x2040 arch/x86/kernel/signal.c:810
exit_to_usermode_loop+0x28a/0x310 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455a09
RSP: 002b:00007f9890c42ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 000000000072bec8 RCX: 0000000000455a09
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000072bec8
RBP: 000000000072bec8 R08: 0000000000000000 R09: 000000000072bea0
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffcb48ac3ff R14: 00007f9890c439c0 R15: 0000000000000000
Code: ff 48 c1 e9 03 80 3c 19 00 0f 85 a9 05 00 00 49 8b 4f 18 48 8b 85 98
fe ff ff 48 89 ce c6 00 00 48 c1 ee 03 48 89 95 d8 fe ff ff <80> 3c 1e 00
0f 85 c6 05 00 00 48 8b 85 98 fe ff ff 48 85 d2 48
RIP: __hlist_del include/linux/list.h:649 [inline] RSP: ffff8801a8f8ef70
RIP: hlist_del_rcu include/linux/rculist.h:427 [inline] RSP:
ffff8801a8f8ef70
RIP: bpf_tcp_close+0x7d2/0xf80 kernel/bpf/sockmap.c:271 RSP:
ffff8801a8f8ef70
---[ end trace e81227e93c7e7b75 ]---
---
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 1/2] batman-adv: Remove "default n" in Kconfig
From: Sergei Shtylyov @ 2018-05-26 9:13 UTC (permalink / raw)
To: Sven Eckelmann, davem; +Cc: netdev, b.a.t.m.a.n, a, sw, mareklindner, joe
In-Reply-To: <20180525194837.12589-1-sven@narfation.org>
On 5/25/2018 10:48 PM, Sven Eckelmann wrote:
> The "default n" is the default value for any bool or tristate Kconfig
> setting. It is therefore not necessary to add it to the an config entry.
^^^^^^
One article would be enough. And it's "a", not "an" in this case. :-)
> Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Signed-off-by: Sven Eckelmann <sven@narfation.org>
[...]
MBR, Sergei
^ permalink raw reply
* general protection fault in sock_do_ioctl
From: syzbot @ 2018-05-26 9:14 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 62c8a069b510 net: mvpp2: Add missing VLAN tag detection
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10ad5827800000
kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
dashboard link: https://syzkaller.appspot.com/bug?extid=09b980aff7b322aac68d
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+09b980aff7b322aac68d@syzkaller.appspotmail.com
__sys_sendmsg+0x115/0x270 net/socket.c:2155
kasan: CONFIG_KASAN_INLINE enabled
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162
kasan: GPF could be caused by NULL-ptr deref or user memory access
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Modules linked in:
RIP: 0033:0x455a09
RSP: 002b:00007f7f8526bc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
CPU: 0 PID: 8176 Comm: syz-executor2 Not tainted 4.17.0-rc4+ #53
RAX: ffffffffffffffda RBX: 00007f7f8526c6d4 RCX: 0000000000455a09
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RDX: 0000000000000000 RSI: 00000000200019c0 RDI: 0000000000000013
RIP: 0010:smc_tx_prepared_sends net/smc/smc_tx.h:27 [inline]
RIP: 0010:smc_ioctl+0x6db/0x9f0 net/smc/af_smc.c:1506
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
RSP: 0018:ffff8801afe4f770 EFLAGS: 00010202
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000014
R13: 000000000000059b R14: 00000000006fc728 R15: 0000000000000005
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: dffffc0000000000
RDX: 0000000000000004 RSI: 1ffff10035fc9f0d RDI: 0000000000000020
RBP: ffff8801afe4f9d0 R08: ffffed0035fc9f0e R09: ffffed0035fc9f0d
R10: ffffed0035fc9f0d R11: ffff8801afe4f86f R12: 1ffff10035fc9ef1
R13: 00000000200003c0 R14: ffff8801afe4f868 R15: ffff8801afe4f828
FS: 00007f6710832700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000007270dc CR3: 00000001c83ae000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
sock_do_ioctl+0xe4/0x3e0 net/socket.c:957
sock_ioctl+0x30d/0x680 net/socket.c:1081
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
__do_sys_ioctl fs/ioctl.c:708 [inline]
__se_sys_ioctl fs/ioctl.c:706 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 1 PID: 8189 Comm: syz-executor5 Not tainted 4.17.0-rc4+ #53
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Call Trace:
RIP: 0033:0x455a09
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
RSP: 002b:00007f6710831c68 EFLAGS: 00000246
ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f67108326d4 RCX: 0000000000455a09
fail_dump lib/fault-inject.c:51 [inline]
should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
RDX: 00000000200003c0 RSI: 000000000000894b RDI: 0000000000000013
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 000000000000044c R14: 00000000006fa7c0 R15: 0000000000000000
Code:
f8
48
c1
e8
03
80
3c
10
00
0f
85
ed
01
00
00
48
8b
9b
__should_failslab+0x124/0x180 mm/failslab.c:32
90
should_failslab+0x9/0x14 mm/slab_common.c:1522
04
slab_pre_alloc_hook mm/slab.h:423 [inline]
slab_alloc mm/slab.c:3378 [inline]
kmem_cache_alloc+0x47/0x760 mm/slab.c:3552
00
00
48
kmem_cache_zalloc include/linux/slab.h:691 [inline]
fill_pool lib/debugobjects.c:134 [inline]
__debug_object_init+0xbc0/0x12c0 lib/debugobjects.c:377
b8
00
00
00
00
00 fc
ff
df
48
8d
7b
20
48
89
fa
48
c1
ea
03
<0f>
b6
04
02
84
c0
74
08
3c
03
debug_object_init+0x16/0x20 lib/debugobjects.c:429
0f
debug_timer_init kernel/time/timer.c:704 [inline]
debug_init kernel/time/timer.c:757 [inline]
init_timer_key+0xa1/0x470 kernel/time/timer.c:806
8e
b7
01
00
00
sctp_association_init net/sctp/associola.c:152 [inline]
sctp_association_new+0xa90/0x2170 net/sctp/associola.c:312
8b
43
20
49
8d
RIP: smc_tx_prepared_sends net/smc/smc_tx.h:27 [inline] RSP:
ffff8801afe4f770
RIP: smc_ioctl+0x6db/0x9f0 net/smc/af_smc.c:1506 RSP: ffff8801afe4f770
---[ end trace ed404e46621ff58c ]---
---
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
* WARNING in bpf_int_jit_compile
From: syzbot @ 2018-05-26 9:14 UTC (permalink / raw)
To: ast, daniel, davem, hpa, kuznet, linux-kernel, mingo, netdev,
syzkaller-bugs, tglx, x86, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 203ec2fed17a Merge tag 'armsoc-fixes' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14f0d5a7800000
kernel config: https://syzkaller.appspot.com/x/.config?x=f3b4e30da84ec1ed
dashboard link: https://syzkaller.appspot.com/bug?extid=9e762b52dd17e616a7a5
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+9e762b52dd17e616a7a5@syzkaller.appspotmail.com
RAX: ffffffffffffffda RBX: 00007f9da107d6d4 RCX: 0000000000455a09
RDX: 0000000000000048 RSI: 000000002000e000 RDI: 0000000000000005
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000014
R13: 0000000000000046 R14: 00000000006f4730 R15: 0000000000000021
WARNING: CPU: 0 PID: 20757 at include/linux/filter.h:667
bpf_jit_binary_lock_ro include/linux/filter.h:667 [inline]
WARNING: CPU: 0 PID: 20757 at include/linux/filter.h:667
bpf_int_jit_compile+0xbf7/0xef7 arch/x86/net/bpf_jit_comp.c:1271
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 20757 Comm: syz-executor6 Not tainted 4.17.0-rc5+ #60
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+0x1b9/0x294 lib/dump_stack.c:113
panic+0x22f/0x4de kernel/panic.c:184
__warn.cold.8+0x163/0x1b3 kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:bpf_jit_binary_lock_ro include/linux/filter.h:667 [inline]
RIP: 0010:bpf_int_jit_compile+0xbf7/0xef7 arch/x86/net/bpf_jit_comp.c:1271
RSP: 0018:ffff8801b3fbf920 EFLAGS: 00010246
RAX: 0000000000040000 RBX: 0000000000000047 RCX: ffffc900050da000
RDX: 0000000000040000 RSI: ffffffff81444d37 RDI: 0000000000000005
RBP: ffff8801b3fbfa40 R08: ffff8801b4c18040 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90001932002
R13: ffff8801b3fbfa18 R14: 00000000fffffff4 R15: 0000000000000003
bpf_prog_select_runtime+0x131/0x640 kernel/bpf/core.c:1491
bpf_prog_load+0x16c2/0x2070 kernel/bpf/syscall.c:1333
__do_sys_bpf kernel/bpf/syscall.c:2073 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2035 [inline]
__x64_sys_bpf+0x389/0x4c0 kernel/bpf/syscall.c:2035
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455a09
RSP: 002b:00007f9da107cc68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00007f9da107d6d4 RCX: 0000000000455a09
RDX: 0000000000000048 RSI: 000000002000e000 RDI: 0000000000000005
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000014
R13: 0000000000000046 R14: 00000000006f4730 R15: 0000000000000021
Dumping ftrace buffer:
(ftrace buffer empty)
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
* Re: WARNING in bpf_int_jit_compile
From: syzbot @ 2018-05-26 9:29 UTC (permalink / raw)
To: ast, daniel, davem, hpa, kuznet, linux-kernel, mingo, netdev,
syzkaller-bugs, tglx, x86, yoshfuji
In-Reply-To: <0000000000003cdd01056d184e6e@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 62d18ecfa641 Merge tag 'arm64-fixes' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14c6bf57800000
kernel config: https://syzkaller.appspot.com/x/.config?x=982e2df1b9e60b02
dashboard link: https://syzkaller.appspot.com/bug?extid=9e762b52dd17e616a7a5
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=130e42b7800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9e762b52dd17e616a7a5@syzkaller.appspotmail.com
RAX: ffffffffffffffda RBX: 0000000002542914 RCX: 0000000000455a09
RDX: 0000000000000048 RSI: 0000000020000240 RDI: 0000000000000005
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
R13: 0000000000000046 R14: 00000000006f4730 R15: 0000000000000023
WARNING: CPU: 0 PID: 4752 at include/linux/filter.h:667
bpf_jit_binary_lock_ro include/linux/filter.h:667 [inline]
WARNING: CPU: 0 PID: 4752 at include/linux/filter.h:667
bpf_int_jit_compile+0xbf7/0xef7 arch/x86/net/bpf_jit_comp.c:1271
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 4752 Comm: syz-executor0 Not tainted 4.17.0-rc6+ #67
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+0x1b9/0x294 lib/dump_stack.c:113
panic+0x22f/0x4de kernel/panic.c:184
__warn.cold.8+0x163/0x1b3 kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:bpf_jit_binary_lock_ro include/linux/filter.h:667 [inline]
RIP: 0010:bpf_int_jit_compile+0xbf7/0xef7 arch/x86/net/bpf_jit_comp.c:1271
RSP: 0018:ffff8801d85ff920 EFLAGS: 00010293
RAX: ffff8801d78c40c0 RBX: 0000000000000046 RCX: ffffffff81445d89
RDX: 0000000000000000 RSI: ffffffff81445d97 RDI: 0000000000000005
RBP: ffff8801d85ffa40 R08: ffff8801d78c40c0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000194e002
R13: ffff8801d85ffa18 R14: 00000000fffffff4 R15: 0000000000000003
bpf_prog_select_runtime+0x131/0x640 kernel/bpf/core.c:1541
bpf_prog_load+0x16c2/0x2070 kernel/bpf/syscall.c:1333
__do_sys_bpf kernel/bpf/syscall.c:2073 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2035 [inline]
__x64_sys_bpf+0x389/0x4c0 kernel/bpf/syscall.c:2035
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455a09
RSP: 002b:00007ffec3da2868 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 0000000002542914 RCX: 0000000000455a09
RDX: 0000000000000048 RSI: 0000000020000240 RDI: 0000000000000005
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
R13: 0000000000000046 R14: 00000000006f4730 R15: 0000000000000023
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* Re: [PATCH] rtnetlink: Add more well known protocol values
From: Sergei Shtylyov @ 2018-05-26 9:37 UTC (permalink / raw)
To: Donald Sharp, netdev, dsahern
In-Reply-To: <20180525182050.26056-1-sharpd@cumulusnetworks.com>
Hello!
On 5/25/2018 9:20 PM, Donald Sharp wrote:
> FRRouting installs routes into the kernel associated with
> the originating protocol. Add these values to the well
> known values in rtnetlink.h.
>
> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
> ---
> include/uapi/linux/rtnetlink.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
> index cabb210c93af..81b33826f818 100644
> --- a/include/uapi/linux/rtnetlink.h
> +++ b/include/uapi/linux/rtnetlink.h
> @@ -254,6 +254,11 @@ enum {
> #define RTPROT_DHCP 16 /* DHCP client */
> #define RTPROT_MROUTED 17 /* Multicast daemon */
> #define RTPROT_BABEL 42 /* Babel daemon */
> +#define RTPROT_BGP 186 /* BGP Routes */
> +#define RTPROT_ISIS 187 /* ISIS Routes */
> +#define RTPROT_OSPF 188 /* OSPF Routes */
> +#define RTPROT_RIP 189 /* RIP Routes */
> +#define RTPROT_EIGRP 192 /* EIGRP Routes */
The preceding entries use tab to indent the value, yours use spaces. Not
good...
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH net-next] net: bpfilter: make function bpfilter_mbox_request() static
From: Wei Yongjun @ 2018-05-26 9:47 UTC (permalink / raw)
To: Alexey Kuznetsov, Hideaki YOSHIFUJI, Alexei Starovoitov
Cc: Wei Yongjun, netdev, kernel-janitors
Fixes the following sparse warnings:
net/ipv4/bpfilter/sockopt.c:13:5: warning:
symbol 'bpfilter_mbox_request' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
net/ipv4/bpfilter/sockopt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/bpfilter/sockopt.c b/net/ipv4/bpfilter/sockopt.c
index 42a96d2..5e04ed2 100644
--- a/net/ipv4/bpfilter/sockopt.c
+++ b/net/ipv4/bpfilter/sockopt.c
@@ -10,8 +10,9 @@
unsigned int optlen, bool is_set);
EXPORT_SYMBOL_GPL(bpfilter_process_sockopt);
-int bpfilter_mbox_request(struct sock *sk, int optname, char __user *optval,
- unsigned int optlen, bool is_set)
+static int bpfilter_mbox_request(struct sock *sk, int optname,
+ char __user *optval,
+ unsigned int optlen, bool is_set)
{
if (!bpfilter_process_sockopt) {
int err = request_module("bpfilter");
^ permalink raw reply related
* [PATCH v2 1/2] batman-adv: Remove "default n" in Kconfig
From: Sven Eckelmann @ 2018-05-26 9:40 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, a, sw, mareklindner, joe, sergei.shtylyov,
Sven Eckelmann
The "default n" is the default value for any bool or tristate Kconfig
setting. It is therefore not necessary to add it to a config entry.
Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
v2: changed "the an config entry" to "a config entry" in commit message
net/batman-adv/Kconfig | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/batman-adv/Kconfig b/net/batman-adv/Kconfig
index de8034d80623..41bb67d70c83 100644
--- a/net/batman-adv/Kconfig
+++ b/net/batman-adv/Kconfig
@@ -24,7 +24,6 @@ config BATMAN_ADV
depends on NET
select CRC16
select LIBCRC32C
- default n
help
B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is
a routing protocol for multi-hop ad-hoc mesh networks. The
@@ -60,7 +59,6 @@ config BATMAN_ADV_BLA
config BATMAN_ADV_DAT
bool "Distributed ARP Table"
depends on BATMAN_ADV && INET
- default n
help
This option enables DAT (Distributed ARP Table), a DHT based
mechanism that increases ARP reliability on sparse wireless
@@ -70,7 +68,6 @@ config BATMAN_ADV_DAT
config BATMAN_ADV_NC
bool "Network Coding"
depends on BATMAN_ADV
- default n
help
This option enables network coding, a mechanism that aims to
increase the overall network throughput by fusing multiple
@@ -84,7 +81,6 @@ config BATMAN_ADV_NC
config BATMAN_ADV_MCAST
bool "Multicast optimisation"
depends on BATMAN_ADV && INET && !(BRIDGE=m && BATMAN_ADV=y)
- default n
help
This option enables the multicast optimisation which aims to
reduce the air overhead while improving the reliability of
@@ -94,7 +90,6 @@ config BATMAN_ADV_DEBUGFS
bool "batman-adv debugfs entries"
depends on BATMAN_ADV
depends on DEBUG_FS
- default n
help
Enable this to export routing related debug tables via debugfs.
The information for each soft-interface and used hard-interface can be
--
2.17.0
^ permalink raw reply related
* [PATCH v2 2/2] batman-adv: Drop "experimental" from BATMAN_V Kconfig
From: Sven Eckelmann @ 2018-05-26 9:40 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, a, sw, mareklindner, joe, sergei.shtylyov,
Sven Eckelmann
In-Reply-To: <20180526094032.10044-1-sven@narfation.org>
The Kconfig option BATMAN_ADV_BATMAN_V is now enabled by default when the
BATMAN_ADV is enabled. A feature which is enabled by default for a module
should not be considered experimental.
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
v2: no change
net/batman-adv/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/Kconfig b/net/batman-adv/Kconfig
index 41bb67d70c83..da0b7aa98be9 100644
--- a/net/batman-adv/Kconfig
+++ b/net/batman-adv/Kconfig
@@ -32,7 +32,7 @@ config BATMAN_ADV
tools.
config BATMAN_ADV_BATMAN_V
- bool "B.A.T.M.A.N. V protocol (experimental)"
+ bool "B.A.T.M.A.N. V protocol"
depends on BATMAN_ADV && !(CFG80211=m && BATMAN_ADV=y)
default y
help
--
2.17.0
^ permalink raw reply related
* [PATCH net-next] netfilter: nat: make symbol nat_hook static
From: Wei Yongjun @ 2018-05-26 9:48 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal
Cc: Wei Yongjun, netfilter-devel, coreteam, netdev, kernel-janitors
Fixes the following sparse warning:
net/netfilter/nf_nat_core.c:1039:20: warning:
symbol 'nat_hook' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
net/netfilter/nf_nat_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
index 821f8d8..b7df32a 100644
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -1036,7 +1036,7 @@ void nf_nat_unregister_fn(struct net *net, const struct nf_hook_ops *ops,
.size = sizeof(struct nat_net),
};
-struct nf_nat_hook nat_hook = {
+static struct nf_nat_hook nat_hook = {
.parse_nat_setup = nfnetlink_parse_nat_setup,
#ifdef CONFIG_XFRM
.decode_session = __nf_nat_decode_session,
^ permalink raw reply related
* Is it possible to get device information via CMSG?
From: Eric S. Raymond @ 2018-05-26 9:39 UTC (permalink / raw)
To: netdev
I'm trying to untangle some nasty code in the Mills implementation of
NTP. I could simplify it a lot if there were a way to query a packet
to find out the name of the network interface it arrived on. (At the
moment the code has to iterate over all interfaces checking for
traffic on each one just so it doesn't lose that information.)
This seems like the kind of thing the CMSG macros are intended to
support, but I can't find anywhere a specification of what cmsg_level
and cmsg_type values are valid and what their semantics are.
So I have two questions:
1. Is there a cmsg_level/cmsg_type combination that will return the
name of the device the packet arrived through?
2. Is the set of possible cmsg_level and cmsg_type values documented
anywhere? If not, how would one go about assemnbling such information?
(I would be willing to write a man page about this.)
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
You [should] not examine legislation in the light of the benefits it will
convey if properly administered, but in the light of the wrongs it
would do and the harm it would cause if improperly administered
-- Lyndon Johnson, former President of the U.S.
^ permalink raw reply
* Re: System hung for reg_check_changs_work()-> rtnl_lock()->mutex_lock()
From: Dmitry Vyukov @ 2018-05-26 10:19 UTC (permalink / raw)
To: Shawn Lin; +Cc: netdev, David S. Miller, syzkaller-bugs
In-Reply-To: <aa65282a-b7f9-757f-8690-64c27df44e90@rock-chips.com>
On Mon, May 21, 2018 at 5:47 AM, Shawn Lin <shawn.lin@rock-chips.com> wrote:
> Hi,
>
> I found this hung for several times these days, and seems syzbot already
> reported a similar problem. Is there any patch(es) for that?
>
> Successfully initialized wpa_supplicant
> [ 240.091941] INFO: task kworker/u8:1:39 blocked for more than 120 seconds.
> [ 240.092004] Not tainted 4.4.126 #1
> [ 240.092026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [ 240.092047] kworker/u8:1 D ffffff8008084dfc 0 39 2
> 0x00000000
> [ 240.092116] Workqueue: events_power_efficient reg_check_chans_work
> [ 240.092153] Call trace:
> [ 240.092191] [<ffffff8008084dfc>] __switch_to+0x84/0xa0
> [ 240.092228] [<ffffff80086299f0>] __schedule+0x428/0x45c
> [ 240.092260] [<ffffff8008629a98>] schedule+0x74/0x94
> [ 240.092295] [<ffffff8008629e44>] schedule_preempt_disabled+0x20/0x38
> [ 240.092332] [<ffffff800862b13c>] __mutex_lock_slowpath+0xc0/0x138
> [ 240.092364] [<ffffff800862b1e0>] mutex_lock+0x2c/0x40
> [ 240.092399] [<ffffff80084eb820>] rtnl_lock+0x14/0x1c
> [ 240.092428] [<ffffff80085ce2a0>] reg_check_chans_work+0x2c/0x1f0
> [ 240.092463] [<ffffff80080abbac>] process_one_work+0x1b0/0x294
> [ 240.092494] [<ffffff80080ac904>] worker_thread+0x2d8/0x398
> [ 240.092524] [<ffffff80080b0f04>] kthread+0xc8/0xd8
> [ 240.092567] [<ffffff8008082e80>] ret_from_fork+0x10/0x50
> [ 240.092594] Kernel panic - not syncing: hung_task: blocked tasks
> [ 240.101163] CPU: 0 PID: 30 Comm: khungtaskd Not tainted 4.4.126 #1
> [ 240.101729] Hardware name: Rockchip RK3308 evb analog mic board (DT)
> [ 240.102302] Call trace:
> [ 240.102546] [<ffffff800808731c>] dump_backtrace+0x0/0x1c4
> [ 240.103044] [<ffffff80080874f4>] show_stack+0x14/0x1c
> [ 240.103521] [<ffffff800823f4b4>] dump_stack+0x94/0xbc
> [ 240.104000] [<ffffff800810a80c>] panic+0xd8/0x228
> [ 240.104446] [<ffffff80080fb228>] proc_dohung_task_timeout_secs+0x0/0x40
> [ 240.105050] [<ffffff80080b0f04>] kthread+0xc8/0xd8
> [ 240.105500] [<ffffff8008082e80>] ret_from_fork+0x10/0x50
> [ 240.106065] CPU1: stopping
> [ 240.106348] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.126 #1
Syzbot has reported whole bunch of hangs on rtnl lock, but there is no
resolution:
https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
I suspect this can be related to hangs in unregister_netdevice:
https://syzkaller.appspot.com/bug?id=1a97a5bd119fd97995f752819fd87840ab9479a9
They happen all the time too, there is no resolution for this either.
Also see this thread:
https://groups.google.com/d/msg/syzkaller/-06_laheMF0/xqezy58kAwAJ
^ permalink raw reply
* [PATCH net-next] net: remove unnecessary genlmsg_cancel() calls
From: YueHaibing @ 2018-05-26 11:15 UTC (permalink / raw)
To: davem, jiri
Cc: netdev, linux-kernel, johannes, kvalo, kuznet, yoshfuji, sameo,
linux-wireless, YueHaibing
the message be freed immediately, no need to trim it
back to the previous size.
Inspired by commit 7a9b3ec1e19f ("nl80211: remove unnecessary genlmsg_cancel() calls")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/team/team.c | 2 --
drivers/net/wireless/mac80211_hwsim.c | 1 -
net/core/devlink.c | 4 ----
net/ipv6/seg6.c | 1 -
net/ncsi/ncsi-netlink.c | 1 -
net/nfc/netlink.c | 17 -----------------
6 files changed, 26 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index e6730a0..267dcc9 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -2426,7 +2426,6 @@ static int team_nl_send_options_get(struct team *team, u32 portid, u32 seq,
nla_put_failure:
err = -EMSGSIZE;
errout:
- genlmsg_cancel(skb, hdr);
nlmsg_free(skb);
return err;
}
@@ -2720,7 +2719,6 @@ static int team_nl_send_port_list_get(struct team *team, u32 portid, u32 seq,
nla_put_failure:
err = -EMSGSIZE;
errout:
- genlmsg_cancel(skb, hdr);
nlmsg_free(skb);
return err;
}
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index c26469b..38e1135 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2514,7 +2514,6 @@ static void hwsim_mcast_new_radio(int id, struct genl_info *info,
return;
out_err:
- genlmsg_cancel(mcast_skb, data);
nlmsg_free(mcast_skb);
}
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 475246b..f75ee02 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -1826,7 +1826,6 @@ static int devlink_dpipe_tables_fill(struct genl_info *info,
nla_put_failure:
err = -EMSGSIZE;
err_table_put:
- genlmsg_cancel(skb, hdr);
nlmsg_free(skb);
return err;
}
@@ -2032,7 +2031,6 @@ int devlink_dpipe_entry_ctx_prepare(struct devlink_dpipe_dump_ctx *dump_ctx)
return 0;
nla_put_failure:
- genlmsg_cancel(dump_ctx->skb, dump_ctx->hdr);
nlmsg_free(dump_ctx->skb);
return -EMSGSIZE;
}
@@ -2249,7 +2247,6 @@ static int devlink_dpipe_headers_fill(struct genl_info *info,
nla_put_failure:
err = -EMSGSIZE;
err_table_put:
- genlmsg_cancel(skb, hdr);
nlmsg_free(skb);
return err;
}
@@ -2551,7 +2548,6 @@ static int devlink_resource_fill(struct genl_info *info,
err = -EMSGSIZE;
err_resource_put:
err_skb_send_alloc:
- genlmsg_cancel(skb, hdr);
nlmsg_free(skb);
return err;
}
diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c
index 7f5621d..0fdf2a5 100644
--- a/net/ipv6/seg6.c
+++ b/net/ipv6/seg6.c
@@ -226,7 +226,6 @@ static int seg6_genl_get_tunsrc(struct sk_buff *skb, struct genl_info *info)
nla_put_failure:
rcu_read_unlock();
- genlmsg_cancel(msg, hdr);
free_msg:
nlmsg_free(msg);
return -ENOMEM;
diff --git a/net/ncsi/ncsi-netlink.c b/net/ncsi/ncsi-netlink.c
index b09ef77..99f4c22 100644
--- a/net/ncsi/ncsi-netlink.c
+++ b/net/ncsi/ncsi-netlink.c
@@ -201,7 +201,6 @@ static int ncsi_pkg_info_nl(struct sk_buff *msg, struct genl_info *info)
return genlmsg_reply(skb, info);
err:
- genlmsg_cancel(skb, hdr);
kfree_skb(skb);
return rc;
}
diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
index f018eaf..376181c 100644
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -206,7 +206,6 @@ int nfc_genl_targets_found(struct nfc_dev *dev)
return genlmsg_multicast(&nfc_genl_family, msg, 0, 0, GFP_ATOMIC);
nla_put_failure:
- genlmsg_cancel(msg, hdr);
free_msg:
nlmsg_free(msg);
return -EMSGSIZE;
@@ -237,7 +236,6 @@ int nfc_genl_target_lost(struct nfc_dev *dev, u32 target_idx)
return 0;
nla_put_failure:
- genlmsg_cancel(msg, hdr);
free_msg:
nlmsg_free(msg);
return -EMSGSIZE;
@@ -269,7 +267,6 @@ int nfc_genl_tm_activated(struct nfc_dev *dev, u32 protocol)
return 0;
nla_put_failure:
- genlmsg_cancel(msg, hdr);
free_msg:
nlmsg_free(msg);
return -EMSGSIZE;
@@ -299,7 +296,6 @@ int nfc_genl_tm_deactivated(struct nfc_dev *dev)
return 0;
nla_put_failure:
- genlmsg_cancel(msg, hdr);
free_msg:
nlmsg_free(msg);
return -EMSGSIZE;
@@ -340,7 +336,6 @@ int nfc_genl_device_added(struct nfc_dev *dev)
return 0;
nla_put_failure:
- genlmsg_cancel(msg, hdr);
free_msg:
nlmsg_free(msg);
return -EMSGSIZE;
@@ -370,7 +365,6 @@ int nfc_genl_device_removed(struct nfc_dev *dev)
return 0;
nla_put_failure:
- genlmsg_cancel(msg, hdr);
free_msg:
nlmsg_free(msg);
return -EMSGSIZE;
@@ -434,8 +428,6 @@ int nfc_genl_llc_send_sdres(struct nfc_dev *dev, struct hlist_head *sdres_list)
return genlmsg_multicast(&nfc_genl_family, msg, 0, 0, GFP_ATOMIC);
nla_put_failure:
- genlmsg_cancel(msg, hdr);
-
free_msg:
nlmsg_free(msg);
@@ -470,7 +462,6 @@ int nfc_genl_se_added(struct nfc_dev *dev, u32 se_idx, u16 type)
return 0;
nla_put_failure:
- genlmsg_cancel(msg, hdr);
free_msg:
nlmsg_free(msg);
return -EMSGSIZE;
@@ -501,7 +492,6 @@ int nfc_genl_se_removed(struct nfc_dev *dev, u32 se_idx)
return 0;
nla_put_failure:
- genlmsg_cancel(msg, hdr);
free_msg:
nlmsg_free(msg);
return -EMSGSIZE;
@@ -546,7 +536,6 @@ int nfc_genl_se_transaction(struct nfc_dev *dev, u8 se_idx,
return 0;
nla_put_failure:
- genlmsg_cancel(msg, hdr);
free_msg:
/* evt_transaction is no more used */
devm_kfree(&dev->dev, evt_transaction);
@@ -585,7 +574,6 @@ int nfc_genl_se_connectivity(struct nfc_dev *dev, u8 se_idx)
return 0;
nla_put_failure:
- genlmsg_cancel(msg, hdr);
free_msg:
nlmsg_free(msg);
return -EMSGSIZE;
@@ -703,7 +691,6 @@ int nfc_genl_dep_link_up_event(struct nfc_dev *dev, u32 target_idx,
return 0;
nla_put_failure:
- genlmsg_cancel(msg, hdr);
free_msg:
nlmsg_free(msg);
return -EMSGSIZE;
@@ -735,7 +722,6 @@ int nfc_genl_dep_link_down_event(struct nfc_dev *dev)
return 0;
nla_put_failure:
- genlmsg_cancel(msg, hdr);
free_msg:
nlmsg_free(msg);
return -EMSGSIZE;
@@ -1030,7 +1016,6 @@ static int nfc_genl_send_params(struct sk_buff *msg,
return 0;
nla_put_failure:
-
genlmsg_cancel(msg, hdr);
return -EMSGSIZE;
}
@@ -1290,7 +1275,6 @@ int nfc_genl_fw_download_done(struct nfc_dev *dev, const char *firmware_name,
return 0;
nla_put_failure:
- genlmsg_cancel(msg, hdr);
free_msg:
nlmsg_free(msg);
return -EMSGSIZE;
@@ -1507,7 +1491,6 @@ static void se_io_cb(void *context, u8 *apdu, size_t apdu_len, int err)
return;
nla_put_failure:
- genlmsg_cancel(msg, hdr);
free_msg:
nlmsg_free(msg);
kfree(ctx);
--
2.7.0
^ permalink raw reply related
* Re: [PATCH v4 2/3] media: rc: introduce BPF_PROG_LIRC_MODE2
From: Sean Young @ 2018-05-26 12:17 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: linux-media, linux-kernel, Alexei Starovoitov,
Mauro Carvalho Chehab, Daniel Borkmann, netdev, Matthias Reichl,
Devin Heitmueller, Y Song, Quentin Monnet
In-Reply-To: <20180525204509.7jsnnk2qzws3bmyd@ast-mbp>
On Fri, May 25, 2018 at 01:45:11PM -0700, Alexei Starovoitov wrote:
> On Fri, May 18, 2018 at 03:07:29PM +0100, Sean Young wrote:
> > Add support for BPF_PROG_LIRC_MODE2. This type of BPF program can call
> > rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report
> > that the last key should be repeated.
> >
> > The bpf program can be attached to using the bpf(BPF_PROG_ATTACH) syscall;
> > the target_fd must be the /dev/lircN device.
> >
> > Signed-off-by: Sean Young <sean@mess.org>
> ...
> > enum bpf_attach_type {
> > @@ -158,6 +159,7 @@ enum bpf_attach_type {
> > BPF_CGROUP_INET6_CONNECT,
> > BPF_CGROUP_INET4_POST_BIND,
> > BPF_CGROUP_INET6_POST_BIND,
> > + BPF_LIRC_MODE2,
> > __MAX_BPF_ATTACH_TYPE
> > };
> >
> > @@ -1902,6 +1904,53 @@ union bpf_attr {
> > * egress otherwise). This is the only flag supported for now.
> > * Return
> > * **SK_PASS** on success, or **SK_DROP** on error.
> > + *
> > + * int bpf_rc_keydown(void *ctx, u32 protocol, u64 scancode, u32 toggle)
> > + * Description
> > + * This helper is used in programs implementing IR decoding, to
> > + * report a successfully decoded key press with *scancode*,
> > + * *toggle* value in the given *protocol*. The scancode will be
> > + * translated to a keycode using the rc keymap, and reported as
> > + * an input key down event. After a period a key up event is
> > + * generated. This period can be extended by calling either
> > + * **bpf_rc_keydown** () with the same values, or calling
> > + * **bpf_rc_repeat** ().
> > + *
> > + * Some protocols include a toggle bit, in case the button
> > + * was released and pressed again between consecutive scancodes
> > + *
> > + * The *ctx* should point to the lirc sample as passed into
> > + * the program.
> > + *
> > + * The *protocol* is the decoded protocol number (see
> > + * **enum rc_proto** for some predefined values).
> > + *
> > + * This helper is only available is the kernel was compiled with
> > + * the **CONFIG_BPF_LIRC_MODE2** configuration option set to
> > + * "**y**".
> > + *
> > + * Return
> > + * 0
> > + *
> > + * int bpf_rc_repeat(void *ctx)
> > + * Description
> > + * This helper is used in programs implementing IR decoding, to
> > + * report a successfully decoded repeat key message. This delays
> > + * the generation of a key up event for previously generated
> > + * key down event.
> > + *
> > + * Some IR protocols like NEC have a special IR message for
> > + * repeating last button, for when a button is held down.
> > + *
> > + * The *ctx* should point to the lirc sample as passed into
> > + * the program.
> > + *
> > + * This helper is only available is the kernel was compiled with
> > + * the **CONFIG_BPF_LIRC_MODE2** configuration option set to
> > + * "**y**".
>
> Hi Sean,
>
> thank you for working on this. The patch set looks good to me.
> I'd only ask to change above two helper names to something more specific.
> Since BPF_PROG_TYPE_LIRC_MODE2 is the name of new prog type and kconfig.
> May be bpf_lirc2_keydown() and bpf_lirc2_repeat() ?
A little history might help here.
lirc and rc-core have non-obvious meanings. So, lirc was the original project
that dealt with IR. That project was rejected from mainline because it did
not send translated keycodes to input devices (it exposed its own interface
for keypresses).
Then rc-core was written which maps IR scancodes to keycodes (using rc
keymaps) and sends them to the input layer. The original lirc userspace ABI
for receiving and sending raw IR pulses and spaces was retained (mode2 as
it was called in lirc).
Reusing parts of the lirc ABI for BPF decoding raw IR makes sense, however
dispatching decoded scancodes was never part of lirc, only rc-core. In fact,
rc-core is reused in hdmi-cec for cec commands, which does not use lirc
at all. So for example, if we want to process cec messages in bpf, it would
want call rc_keydown().
I don't think this lirc/rc-core duality is particularly great, but I'm
not sure what the right answer to that is.
> > @@ -1576,6 +1577,8 @@ static int bpf_prog_attach(const union bpf_attr *attr)
> > case BPF_SK_SKB_STREAM_PARSER:
> > case BPF_SK_SKB_STREAM_VERDICT:
> > return sockmap_get_from_fd(attr, BPF_PROG_TYPE_SK_SKB, true);
> > + case BPF_LIRC_MODE2:
> > + return rc_dev_prog_attach(attr);
> ...
> > + case BPF_LIRC_MODE2:
> > + return rc_dev_prog_detach(attr);
>
> and similar rename for internal function names that go into bpf core.
I agree with this.
> Please add accumulated acks when you respin.
Good point, will do.
Thanks,
Sean
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: missing headers test_lwt_seg6local
From: Mathieu Xhonneux @ 2018-05-26 12:26 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Alexei Starovoitov, netdev, Y Song
In-Reply-To: <a80ed942-c1ef-a630-fffa-5e16f20d8356@iogearbox.net>
2018-05-25 18:39 GMT+02:00 Daniel Borkmann <daniel@iogearbox.net>:
> Yes, should definitely go there to tools include infrastructure.
What is the point of tools/testing/selftests/bpf/include/uapi/ then ?
Incompatibility issues preventing linux/types.h to be included in
non-bpf testing executables ? My initial conception was that all
headers only related to bpf should go into this directory. Sending a
v2.
^ permalink raw reply
* [PATCH bpf-next v2] selftests/bpf: missing headers test_lwt_seg6local
From: Mathieu Xhonneux @ 2018-05-26 14:44 UTC (permalink / raw)
To: netdev; +Cc: alexei.starovoitov, daniel, ys114321
Previous patch "selftests/bpf: test for seg6local End.BPF action" lacks
some UAPI headers in tools/.
clang -I. -I./include/uapi -I../../../include/uapi -idirafter
/usr/local/include -idirafter
/data/users/yhs/work/llvm/build/install/lib/clang/7.0.0/include
-idirafter /usr/include -Wno-compare-distinct-pointer-types \
-O2 -target bpf -emit-llvm -c test_lwt_seg6local.c -o - | \
llc -march=bpf -mcpu=generic -filetype=obj -o
[...]/net-next/tools/testing/selftests/bpf/test_lwt_seg6local.o
test_lwt_seg6local.c:4:10: fatal error: 'linux/seg6_local.h' file not found
^~~~~~~~~~~~~~~~~~~~
1 error generated.
make: Leaving directory
`/data/users/yhs/work/net-next/tools/testing/selftests/bpf'
v2: moving the headers to tools/include/uapi/.
Reported-by: Y Song <ys114321@gmail.com>
Signed-off-by: Mathieu Xhonneux <m.xhonneux@gmail.com>
---
tools/include/uapi/linux/seg6.h | 55 ++++++++++++++++++++++++
tools/include/uapi/linux/seg6_local.h | 80 +++++++++++++++++++++++++++++++++++
2 files changed, 135 insertions(+)
create mode 100644 tools/include/uapi/linux/seg6.h
create mode 100644 tools/include/uapi/linux/seg6_local.h
diff --git a/tools/include/uapi/linux/seg6.h b/tools/include/uapi/linux/seg6.h
new file mode 100644
index 000000000000..286e8d6a8e98
--- /dev/null
+++ b/tools/include/uapi/linux/seg6.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
+/*
+ * SR-IPv6 implementation
+ *
+ * Author:
+ * David Lebrun <david.lebrun@uclouvain.be>
+ *
+ *
+ * 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.
+ */
+
+#ifndef _UAPI_LINUX_SEG6_H
+#define _UAPI_LINUX_SEG6_H
+
+#include <linux/types.h>
+#include <linux/in6.h> /* For struct in6_addr. */
+
+/*
+ * SRH
+ */
+struct ipv6_sr_hdr {
+ __u8 nexthdr;
+ __u8 hdrlen;
+ __u8 type;
+ __u8 segments_left;
+ __u8 first_segment; /* Represents the last_entry field of SRH */
+ __u8 flags;
+ __u16 tag;
+
+ struct in6_addr segments[0];
+};
+
+#define SR6_FLAG1_PROTECTED (1 << 6)
+#define SR6_FLAG1_OAM (1 << 5)
+#define SR6_FLAG1_ALERT (1 << 4)
+#define SR6_FLAG1_HMAC (1 << 3)
+
+#define SR6_TLV_INGRESS 1
+#define SR6_TLV_EGRESS 2
+#define SR6_TLV_OPAQUE 3
+#define SR6_TLV_PADDING 4
+#define SR6_TLV_HMAC 5
+
+#define sr_has_hmac(srh) ((srh)->flags & SR6_FLAG1_HMAC)
+
+struct sr6_tlv {
+ __u8 type;
+ __u8 len;
+ __u8 data[0];
+};
+
+#endif
diff --git a/tools/include/uapi/linux/seg6_local.h b/tools/include/uapi/linux/seg6_local.h
new file mode 100644
index 000000000000..edc138bdc56d
--- /dev/null
+++ b/tools/include/uapi/linux/seg6_local.h
@@ -0,0 +1,80 @@
+/*
+ * SR-IPv6 implementation
+ *
+ * Author:
+ * David Lebrun <david.lebrun@uclouvain.be>
+ *
+ *
+ * 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.
+ */
+
+#ifndef _UAPI_LINUX_SEG6_LOCAL_H
+#define _UAPI_LINUX_SEG6_LOCAL_H
+
+#include <linux/seg6.h>
+
+enum {
+ SEG6_LOCAL_UNSPEC,
+ SEG6_LOCAL_ACTION,
+ SEG6_LOCAL_SRH,
+ SEG6_LOCAL_TABLE,
+ SEG6_LOCAL_NH4,
+ SEG6_LOCAL_NH6,
+ SEG6_LOCAL_IIF,
+ SEG6_LOCAL_OIF,
+ SEG6_LOCAL_BPF,
+ __SEG6_LOCAL_MAX,
+};
+#define SEG6_LOCAL_MAX (__SEG6_LOCAL_MAX - 1)
+
+enum {
+ SEG6_LOCAL_ACTION_UNSPEC = 0,
+ /* node segment */
+ SEG6_LOCAL_ACTION_END = 1,
+ /* adjacency segment (IPv6 cross-connect) */
+ SEG6_LOCAL_ACTION_END_X = 2,
+ /* lookup of next seg NH in table */
+ SEG6_LOCAL_ACTION_END_T = 3,
+ /* decap and L2 cross-connect */
+ SEG6_LOCAL_ACTION_END_DX2 = 4,
+ /* decap and IPv6 cross-connect */
+ SEG6_LOCAL_ACTION_END_DX6 = 5,
+ /* decap and IPv4 cross-connect */
+ SEG6_LOCAL_ACTION_END_DX4 = 6,
+ /* decap and lookup of DA in v6 table */
+ SEG6_LOCAL_ACTION_END_DT6 = 7,
+ /* decap and lookup of DA in v4 table */
+ SEG6_LOCAL_ACTION_END_DT4 = 8,
+ /* binding segment with insertion */
+ SEG6_LOCAL_ACTION_END_B6 = 9,
+ /* binding segment with encapsulation */
+ SEG6_LOCAL_ACTION_END_B6_ENCAP = 10,
+ /* binding segment with MPLS encap */
+ SEG6_LOCAL_ACTION_END_BM = 11,
+ /* lookup last seg in table */
+ SEG6_LOCAL_ACTION_END_S = 12,
+ /* forward to SR-unaware VNF with static proxy */
+ SEG6_LOCAL_ACTION_END_AS = 13,
+ /* forward to SR-unaware VNF with masquerading */
+ SEG6_LOCAL_ACTION_END_AM = 14,
+ /* custom BPF action */
+ SEG6_LOCAL_ACTION_END_BPF = 15,
+
+ __SEG6_LOCAL_ACTION_MAX,
+};
+
+#define SEG6_LOCAL_ACTION_MAX (__SEG6_LOCAL_ACTION_MAX - 1)
+
+enum {
+ SEG6_LOCAL_BPF_PROG_UNSPEC,
+ SEG6_LOCAL_BPF_PROG,
+ SEG6_LOCAL_BPF_PROG_NAME,
+ __SEG6_LOCAL_BPF_PROG_MAX,
+};
+
+#define SEG6_LOCAL_BPF_PROG_MAX (__SEG6_LOCAL_BPF_PROG_MAX - 1)
+
+#endif
--
2.16.1
^ permalink raw reply related
* RE: [PATCH, net-next] net/mlx5e: fix TLS dependency
From: Boris Pismenny @ 2018-05-26 14:17 UTC (permalink / raw)
To: Saeed Mahameed, davem@davemloft.net, arnd@arndb.de,
leon@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
Or Gerlitz, Feras Daoud, netdev@vger.kernel.org
In-Reply-To: <ffcbcc97b72bd9957a7eafb2553edd1cd7e68dab.camel@mellanox.com>
Acked-by: Boris Pismenny <borisp@mellanox.com>
Thank you.
> -----Original Message-----
> From: Saeed Mahameed
> Sent: Saturday, May 26, 2018 2:19 AM
> To: davem@davemloft.net; arnd@arndb.de; leon@kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-rdma@vger.kernel.org; Boris
> Pismenny <borisp@mellanox.com>; Or Gerlitz <ogerlitz@mellanox.com>;
> Feras Daoud <ferasda@mellanox.com>; Ilan Tayari <ilant@mellanox.com>;
> netdev@vger.kernel.org; Ilya Lesokhin <ilyal@mellanox.com>
> Subject: Re: [PATCH, net-next] net/mlx5e: fix TLS dependency
>
> On Fri, 2018-05-25 at 23:36 +0200, Arnd Bergmann wrote:
> > With CONFIG_TLS=m and MLX5_CORE_EN=y, we get a link failure:
> >
> > drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls_rxtx.o: In
> > function `mlx5e_tls_handle_ooo':
> > tls_rxtx.c:(.text+0x24c): undefined reference to `tls_get_record'
> > drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls_rxtx.o: In
> > function `mlx5e_tls_handle_tx_skb':
> > tls_rxtx.c:(.text+0x9a8): undefined reference to
> > `tls_device_sk_destruct'
> >
> > This narrows down the dependency to only allow the configurations that
> > will actually work. The existing dependency on TLS_DEVICE is not
> > sufficient here since MLX5_EN_TLS is a 'bool' symbol.
> >
> > Fixes: c83294b9efa5 ("net/mlx5e: TLS, Add Innova TLS TX support")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
>
> LGTM
>
> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
>
> Thank you Arnd!
>
>
> > drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> > b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> > index ee6684779d11..2545296a0c08 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> > @@ -91,6 +91,7 @@ config MLX5_EN_TLS
> > bool "TLS cryptography-offload accelaration"
> > depends on MLX5_CORE_EN
> > depends on TLS_DEVICE
> > + depends on TLS=y || MLX5_CORE=m
> > depends on MLX5_ACCEL
> > default n
> > ---help---
^ permalink raw reply
* Re: [PATCH net-next 6/7] net: bridge: Notify about bridge VLANs
From: Vivien Didelot @ 2018-05-26 14:54 UTC (permalink / raw)
To: Petr Machata
Cc: netdev, devel, bridge, jiri, idosch, davem, razvan.stefanescu,
gregkh, stephen, andrew, f.fainelli, nikolay
In-Reply-To: <wihwovrfz62.fsf@dev-r-vrt-156.mtr.labs.mlnx>
Hi Petr,
Petr Machata <petrm@mellanox.com> writes:
> Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
>
>>> + } else {
>>> + err = br_switchdev_port_obj_add(dev, v->vid, flags);
>>> + if (err && err != -EOPNOTSUPP)
>>> + goto out;
>>> }
>>
>> Except that br_switchdev_port_obj_add taking vid and flags arguments
>> seems confusing to me, the change looks good:
>
> I'm not sure what you're aiming at. Both VID and flags are sent with the
> notification, so they need to be passed on to the function somehow. Do
> you have a counterproposal for the API?
I'm only questioning the code organization here, not the functional
aspect which I do agree with. What I'm saying is that you name a new
switchdev helper br_switchdev_port_OBJ_add, which takes VLAN arguments
(vid and flags.) How would you call another eventual helper taking MDB
arguments, br_switchdev_port_OBJ_add again? So something like
br_switchdev_port_VLAN_add would be more intuitive.
At the same time there's an effort to centralize all switchdev helpers
of the bridge layer (i.e. the software -> hardware bridge calls) into
net/bridge/br_switchdev.c, so that file would be more adequate.
You may discard my comments but I think it'd be beneficial to us all to
finally keep a bit of consistency in that bridge layer code.
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH v2] netfilter: properly initialize xt_table_info structure
From: Greg Kroah-Hartman @ 2018-05-26 14:54 UTC (permalink / raw)
To: Florian Westphal, Peter Pi
Cc: Jan Engelhardt, Eric Dumazet, Greg Hackmann, Pablo Neira Ayuso,
Jozsef Kadlecsik, Michal Kubecek, netfilter-devel, coreteam,
netdev
In-Reply-To: <20180518092756.odlyvxcpgbuistqq@breakpoint.cc>
On Fri, May 18, 2018 at 11:27:56AM +0200, Florian Westphal wrote:
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Thu, May 17, 2018 at 12:42:00PM +0200, Jan Engelhardt wrote:
> > >
> > > On Thursday 2018-05-17 12:09, Greg Kroah-Hartman wrote:
> > > >> > --- a/net/netfilter/x_tables.c
> > > >> > +++ b/net/netfilter/x_tables.c
> > > >> > @@ -1183,11 +1183,10 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size)
> > > >> > * than shoot all processes down before realizing there is nothing
> > > >> > * more to reclaim.
> > > >> > */
> > > >> > - info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > > >> > + info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > > >> > if (!info)
> > > >> > return NULL;
> > > >>
> > > >> I am curious, what particular path does not later overwrite the whole zone ?
> > > >
> > > >In do_ipt_get_ctl, the IPT_SO_GET_ENTRIES: option uses a len value that
> > > >can be larger than the size of the structure itself.
> > > >
> > > >Then the data is copied to userspace in copy_entries_to_user() for ipv4
> > > >and v6, and that's where the "bad data"
> > >
> > > If the kernel incorrectly copies more bytes than it should, isn't that
> > > a sign that may be going going past the end of the info buffer?
> > > (And thus, zeroing won't truly fix the issue)
> >
> > No, the buffer size is correct, we just aren't filling up the whole
> > buffer as the data requested is smaller than the buffer size.
>
> I have no objections to the patch but I'd like to understand what
> problem its fixing.
>
> Normal pattern is:
> newinfo = xt_alloc_table_info(tmp.size);
> copy_from_user(newinfo->entries, user + sizeof(tmp), tmp.size);
>
> So inital value of the rule blob area should not matter.
>
> Furthermore, when copying the rule blob back to userspace,
> the kernel is not supposed to copy any padding back to userspace either,
> since commit f32815d21d4d8287336fb9cef4d2d9e0866214c2 only the
> user-relevant parts should be copied (some matches and targets allocate
> kernel-private data such as pointers, and we did use to leak such pointer
> values back to userspace).
Adding Peter to this thread, as he originally reported this issue to
Google back in February.
Peter, I know you reported this against the 4.4 kernel tree, but since
then, commit f32815d21d4d ("xtables: add xt_match, xt_target and data
copy_to_user functions") has been added to the kernel in release 4.11.
In digging through this crazy code path, I think the issue is still
there, but can not verify it for sure.
Is there any way you can run your tests on the 4.14 or newer kernel tree
to see if this issue really is fixed or not?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] rsi: fix spelling mistake "Uknown" -> "Unknown"
From: Colin King @ 2018-05-26 15:00 UTC (permalink / raw)
To: Kalle Valo, David S . Miller, linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in rsi_dbg message text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index bfa7569c85bb..2ca7464b7fa3 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -1103,7 +1103,7 @@ static int rsi_mac80211_ampdu_action(struct ieee80211_hw *hw,
break;
default:
- rsi_dbg(ERR_ZONE, "%s: Uknown AMPDU action\n", __func__);
+ rsi_dbg(ERR_ZONE, "%s: Unknown AMPDU action\n", __func__);
break;
}
--
2.17.0
^ permalink raw reply related
* Proposal
From: Miss Zeliha Omer Faruk @ 2018-05-26 15:25 UTC (permalink / raw)
Hello
Greetings to you please i have a business proposal for you contact me
for more detailes asap thanks.
Best Regards,
Miss.Zeliha ömer faruk
Esentepe Mahallesi Büyükdere
Caddesi Kristal Kule Binasi
No:215
Sisli - Istanbul, Turkey
^ permalink raw reply
* Re: INFO: rcu detected stall in corrupted
From: Dmitry Vyukov @ 2018-05-26 15:28 UTC (permalink / raw)
To: Xin Long
Cc: Marcelo Ricardo Leitner, Eric Dumazet, David Miller,
syzbot+f116bc1994efe725d51b, kuznet, LKML, network dev,
syzkaller-bugs, yoshfuji, dsahern, Roopa Prabhu, linux-sctp
In-Reply-To: <CADvbK_dMq0c9wBHoNbLgXj3ee-Ua1EQiqPgvYxX6pumCpO=ygw@mail.gmail.com>
On Thu, May 24, 2018 at 11:02 AM, Xin Long <lucien.xin@gmail.com> wrote:
> On Thu, May 24, 2018 at 7:13 AM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
>> On Mon, May 21, 2018 at 11:13:46AM -0700, Eric Dumazet wrote:
>>>
>>>
>>> On 05/21/2018 11:09 AM, David Miller wrote:
>>> > From: syzbot <syzbot+f116bc1994efe725d51b@syzkaller.appspotmail.com>
>>> > Date: Mon, 21 May 2018 11:05:02 -0700
>>> >
>>> >> find_match+0x244/0x13a0 net/ipv6/route.c:691
>>> >> find_rr_leaf net/ipv6/route.c:729 [inline]
>>> >> rt6_select net/ipv6/route.c:779 [inline]
>>> >
>>> > Hmmm, endless loop in find_rr_leaf or similar?
>>> >
>>>
>>>
>>> I do not think so, this really looks like SCTP specific
>>> , we now have dozens of traces all sharing :
>>>
>>> sctp_transport_route+0xad/0x450 net/sctp/transport.c:293
>>> sctp_packet_config+0xb89/0xfd0 net/sctp/output.c:123
>>> sctp_outq_flush+0x79c/0x4370 net/sctp/outqueue.c:894
>>> sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
>>> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline]
>>> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
>>> sctp_do_sm+0x596/0x7160 net/sctp/sm_sideeffect.c:1191
>>> sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406
>>> call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
>>>
>>>
>>> Some kind of infinite loop.
>>>
>>> When the hrtimer fires, it can point to any code that sits below but does not necessarily have a bug.
>>
>> Agreed. Xin Long identified the root cause. syzkaller is setting too
>> aggressive parameters to SCTP RTO, leading to issues with the
>> heartbeat timer.
> Right, I will prepare a fix soon with your suggestion rto_min value "HZ/5"
> Thanks.
#syz fix: sctp: not allow to set rto_min with a value below 200 msecs
^ permalink raw reply
* Re: INFO: rcu detected stall in ip_route_output_key_hash
From: Dmitry Vyukov @ 2018-05-26 15:32 UTC (permalink / raw)
To: syzbot
Cc: David Miller, Alexey Kuznetsov, LKML, netdev, syzkaller-bugs,
Hideaki YOSHIFUJI, linux-sctp
In-Reply-To: <000000000000e2e064056c5460e3@google.com>
On Wed, May 16, 2018 at 5:29 PM, syzbot
<syzbot+769a7ccbbb4b5074f125@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 0b7d9978406f Merge branch 'Microsemi-Ocelot-Ethernet-switc..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1138c477800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
> dashboard link: https://syzkaller.appspot.com/bug?extid=769a7ccbbb4b5074f125
> 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+769a7ccbbb4b5074f125@syzkaller.appspotmail.com
>
> netlink: 4 bytes leftover after parsing attributes in process
> `syz-executor2'.
> random: crng init done
> INFO: rcu_sched self-detected stall on CPU
> 1-...!: (121515 ticks this GP) idle=e7e/1/4611686018427387908
> softirq=31362/31362 fqs=7
> (t=125000 jiffies g=16439 c=16438 q=668508)
> rcu_sched kthread starved for 124958 jiffies! g16439 c16438 f0x2
> RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
> RCU grace-period kthread stack dump:
> rcu_sched R running task 23768 9 2 0x80000000
> Call Trace:
> context_switch kernel/sched/core.c:2848 [inline]
> __schedule+0x801/0x1e30 kernel/sched/core.c:3490
> schedule+0xef/0x430 kernel/sched/core.c:3549
> schedule_timeout+0x138/0x240 kernel/time/timer.c:1801
> rcu_gp_kthread+0x6b5/0x1940 kernel/rcu/tree.c:2231
> kthread+0x345/0x410 kernel/kthread.c:238
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
> NMI backtrace for cpu 1
> CPU: 1 PID: 4488 Comm: syz-fuzzer Not tainted 4.17.0-rc4+ #45
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
> nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
> arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
> trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
> rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376
> print_cpu_stall kernel/rcu/tree.c:1525 [inline]
> check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593
> __rcu_pending kernel/rcu/tree.c:3356 [inline]
> rcu_pending kernel/rcu/tree.c:3401 [inline]
> rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763
> update_process_times+0x2d/0x70 kernel/time/timer.c:1636
> tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164
> tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274
> __run_hrtimer kernel/time/hrtimer.c:1398 [inline]
> __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1460
> hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518
> local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
> smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
> RIP: 0010:rcu_is_watching+0x6/0x140 kernel/rcu/tree.c:1071
> RSP: 0000:ffff8801daf06620 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13
> RAX: ffff8801ad526240 RBX: 0000000000000000 RCX: ffffffff86444456
> RDX: 0000000000000100 RSI: ffffffff864444b8 RDI: 0000000000000001
> RBP: ffff8801daf06628 R08: ffff8801ad526240 R09: 0000000000000002
> R10: ffff8801ad526240 R11: 0000000000000000 R12: 1ffff1003b5e0cca
> R13: ffff88008ff1a100 R14: 0000000000000000 R15: ffff8801daf066d0
> rcu_read_unlock include/linux/rcupdate.h:684 [inline]
> ip_route_output_key_hash+0x2cd/0x390 net/ipv4/route.c:2303
> __ip_route_output_key include/net/route.h:124 [inline]
> ip_route_output_flow+0x28/0xc0 net/ipv4/route.c:2557
> ip_route_output_key include/net/route.h:134 [inline]
> sctp_v4_get_dst+0x50e/0x17a0 net/sctp/protocol.c:447
> sctp_transport_route+0x132/0x360 net/sctp/transport.c:303
> sctp_packet_config+0x926/0xdd0 net/sctp/output.c:118
> sctp_outq_select_transport+0x2bb/0x9c0 net/sctp/outqueue.c:877
> sctp_outq_flush_ctrl.constprop.12+0x2ad/0xe60 net/sctp/outqueue.c:911
> sctp_outq_flush+0x2ef/0x3430 net/sctp/outqueue.c:1203
> sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x596/0x7160 net/sctp/sm_sideeffect.c:1191
> sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406
#syz fix: sctp: not allow to set rto_min with a value below 200 msecs
> call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
> expire_timers kernel/time/timer.c:1363 [inline]
> __run_timers+0x79e/0xc50 kernel/time/timer.c:1666
> run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
> __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
> invoke_softirq kernel/softirq.c:365 [inline]
> irq_exit+0x1d1/0x200 kernel/softirq.c:405
> exiting_irq arch/x86/include/asm/apic.h:525 [inline]
> smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
> </IRQ>
> RIP: 0033:0x40b55d
> RSP: 002b:000000c424bedca8 EFLAGS: 00000293 ORIG_RAX: ffffffffffffff13
> RAX: 000000c4244e5470 RBX: 000000004d36768c RCX: 0000000000000000
> RDX: 000000c4244e5470 RSI: 000000000000ffff RDI: 0000000000000000
> RBP: 000000c424bedcc0 R08: 0000000000000000 R09: 0000000000000000
> R10: 00000000009466f2 R11: 0000000000000004 R12: 0000000000000000
> R13: 0000000000000020 R14: 0000000000000013 R15: 0000000000000034
> BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 125s!
> BUG: workqueue lockup - pool cpus=0-1 flags=0x4 nice=0 stuck for 125s!
> Showing busy workqueues and worker pools:
> workqueue events: flags=0x0
> pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=3/256
> in-flight: 2104:do_numa_crng_init
> pending: drbg_async_seed, cache_reap
> pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=9/256
> pending: defense_work_handler, defense_work_handler,
> defense_work_handler, defense_work_handler, defense_work_handler,
> defense_work_handler, check_corruption, vmstat_shepherd, cache_reap
> workqueue events_power_efficient: flags=0x80
> pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
> pending: do_cache_clean
> pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
> pending: check_lifetime, gc_worker
> workqueue writeback: flags=0x4e
> pwq 4: cpus=0-1 flags=0x4 nice=0 active=1/256
> in-flight: 6:wb_workfn
> workqueue ipv6_addrconf: flags=0x40008
> pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/1
> pending: addrconf_verify_work
> workqueue krdsd: flags=0xe000a
> pwq 4: cpus=0-1 flags=0x4 nice=0 active=1/1
> in-flight: 43:rds_connect_worker
> pool 2: cpus=1 node=0 flags=0x0 nice=0 hung=0s workers=4 idle: 24 1980 18
> pool 4: cpus=0-1 flags=0x4 nice=0 hung=0s workers=7 idle: 22 8018 287 6751
> 89
>
>
> ---
> 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/000000000000e2e064056c5460e3%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: INFO: rcu detected stall in sctp_packet_transmit
From: Dmitry Vyukov @ 2018-05-26 15:34 UTC (permalink / raw)
To: Xin Long
Cc: syzbot, davem, LKML, linux-sctp, Marcelo Ricardo Leitner,
network dev, Neil Horman, syzkaller-bugs, Vlad Yasevich
In-Reply-To: <CACT4Y+aG0CdZOe8+Y5+OWsghV2o36UpgAXFE4cCm-Mmv6Cq0oA@mail.gmail.com>
On Wed, May 16, 2018 at 2:12 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Wed, May 16, 2018 at 1:02 PM, Xin Long <lucien.xin@gmail.com> wrote:
>>>> <syzbot+ff0b569fb5111dcd1a36@syzkaller.appspotmail.com> wrote:
>>>>> Hello,
>>>>>
>>>>> syzbot found the following crash on:
>>>>>
>>>>> HEAD commit: 961423f9fcbc Merge branch 'sctp-Introduce-sctp_flush_ctx'
>>>>> git tree: net-next
>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1366aea7800000
>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=51fb0a6913f757db
>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=ff0b569fb5111dcd1a36
>>>>> 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+ff0b569fb5111dcd1a36@syzkaller.appspotmail.com
>>>>>
>>>>> INFO: rcu_sched self-detected stall on CPU
>>>>> 0-....: (1 GPs behind) idle=dae/1/4611686018427387908
>>>>> softirq=93090/93091 fqs=30902
>>>>> (t=125000 jiffies g=51107 c=51106 q=972)
>>>>> NMI backtrace for cpu 0
>>>>> CPU: 0 PID: 24668 Comm: syz-executor6 Not tainted 4.17.0-rc4+ #44
>>>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>>>> Google 01/01/2011
>>>>> Call Trace:
>>>>> <IRQ>
>>>>> __dump_stack lib/dump_stack.c:77 [inline]
>>>>> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>>>>> nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
>>>>> nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
>>>>> arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
>>>>> trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
>>>>> rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376
>>>>> print_cpu_stall kernel/rcu/tree.c:1525 [inline]
>>>>> check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593
>>>>> __rcu_pending kernel/rcu/tree.c:3356 [inline]
>>>>> rcu_pending kernel/rcu/tree.c:3401 [inline]
>>>>> rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763
>>>>> update_process_times+0x2d/0x70 kernel/time/timer.c:1636
>>>>> tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164
>>>>> tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274
>>>>> __run_hrtimer kernel/time/hrtimer.c:1398 [inline]
>>>>> __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1460
>>>>> hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518
>>>>> local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
>>>>> smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050
>>>>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
>>>>> RIP: 0010:sctp_v6_xmit+0x259/0x6b0 net/sctp/ipv6.c:219
>>>>> RSP: 0018:ffff8801dae068e8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
>>>>> RAX: 0000000000000007 RBX: ffff8801bb7ec800 RCX: ffffffff86f1b345
>>>>> RDX: 0000000000000000 RSI: ffffffff86f1b381 RDI: ffff8801b73d97c4
>>>>> RBP: ffff8801dae06988 R08: ffff88019505c300 R09: ffffed003b5c46c2
>>>>> R10: ffffed003b5c46c2 R11: ffff8801dae23613 R12: ffff88011fd57300
>>>>> R13: ffff8801bb7ecec8 R14: 0000000000000029 R15: 0000000000000002
>>>>> sctp_packet_transmit+0x26f6/0x3ba0 net/sctp/output.c:642
>>>>> sctp_outq_flush_transports net/sctp/outqueue.c:1164 [inline]
>>>>> sctp_outq_flush+0x5f5/0x3430 net/sctp/outqueue.c:1212
>>>>> sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
>>>>> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline]
>>>>> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
>>>>> sctp_do_sm+0x596/0x7160 net/sctp/sm_sideeffect.c:1191
>>>>> sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406
>>>> Shocks, this timer event again. Can we try to minimize the repo.syz and
>>>> get a short script, not neccessary to reproduce the issue 100%. we need
>>>> to know what it was doing when this happened.
>>>>
>>>> Thanks.
>>>
>>> It's possible to reply the whole log from console output following
>>> these instructions:
>>> https://github.com/google/syzkaller/blob/master/docs/executing_syzkaller_programs.md
>> Thanks, it's running now.
>> Usually how long will it take to finish running this 5000-line log?
>
> If you run with -repeat=0 then it will run infinitely repeating the
> log again and again. If you see:
>
> parsed 1000 programs
> ...
> executed 5000 programs
>
> then it looped 5 times already. You can run with -repeat=10.
>
> syzbot has tried replaying the log, but for some reason it wasn't able
> to reproduce the crash (maybe accumulated state, or maybe it crashed
> in a different way). You can also try logs from other sctp hangs.
#syz fix: sctp: not allow to set rto_min with a value below 200 msecs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox