* WARNING: ODEBUG bug in enqueue_hrtimer
From: syzbot @ 2018-07-31 12:31 UTC (permalink / raw)
To: davem, linux-can, linux-kernel, mkl, netdev, socketcan,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 527838d470e3 Merge branch 'x86-urgent-for-linus' of git://..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15e90362400000
kernel config: https://syzkaller.appspot.com/x/.config?x=2dc0cd7c2eefb46f
dashboard link: https://syzkaller.appspot.com/bug?extid=3c31c6798616dc2d9ee6
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+3c31c6798616dc2d9ee6@syzkaller.appspotmail.com
netlink: 20 bytes leftover after parsing attributes in process
`syz-executor3'.
------------[ cut here ]------------
ODEBUG: activate not available (active state 0) object type: hrtimer hint:
bcm_tx_timeout_handler+0x0/0x60 net/can/bcm.c:241
WARNING: CPU: 1 PID: 18 at lib/debugobjects.c:329
debug_print_object+0x16a/0x210 lib/debugobjects.c:326
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 18 Comm: ksoftirqd/1 Not tainted 4.18.0-rc7+ #170
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:debug_print_object+0x16a/0x210 lib/debugobjects.c:326
Code: 3a 87 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 92 00 00 00 48 8b 14 dd
20 74 3a 87 4c 89 f6 48 c7 c7 c0 69 3a 87 e8 c6 b0 e6 fd <0f> 0b 83 05 a9
e6 29 05 01 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f
RSP: 0018:ffff8801d9f27680 EFLAGS: 00010086
RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000000000
RDX: 0000000000000100 RSI: ffffffff81632481 RDI: 0000000000000001
RBP: ffff8801d9f276c0 R08: ffff8801d9f0c4c0 R09: ffffed003b623ec2
R10: ffffed003b623ec2 R11: ffff8801db11f617 R12: 0000000000000001
R13: ffffffff87fa0660 R14: ffffffff873a7040 R15: ffffffff816a48f0
debug_object_activate+0x359/0x690 lib/debugobjects.c:513
debug_hrtimer_activate kernel/time/hrtimer.c:416 [inline]
debug_activate kernel/time/hrtimer.c:465 [inline]
enqueue_hrtimer+0x9e/0x540 kernel/time/hrtimer.c:954
__hrtimer_start_range_ns kernel/time/hrtimer.c:1089 [inline]
hrtimer_start_range_ns+0x616/0xd20 kernel/time/hrtimer.c:1115
hrtimer_start include/linux/hrtimer.h:398 [inline]
bcm_tx_start_timer+0x11d/0x1b0 net/can/bcm.c:361
bcm_tx_timeout_tsklet+0x1ab/0x4b0 net/can/bcm.c:392
tasklet_action_common.isra.19+0x26f/0x720 kernel/softirq.c:522
tasklet_action+0x1d/0x20 kernel/softirq.c:540
__do_softirq+0x2e8/0xb17 kernel/softirq.c:292
run_ksoftirqd+0x86/0x100 kernel/softirq.c:653
smpboot_thread_fn+0x417/0x870 kernel/smpboot.c:164
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
======================================================
WARNING: possible circular locking dependency detected
4.18.0-rc7+ #170 Not tainted
------------------------------------------------------
ksoftirqd/1/18 is trying to acquire lock:
000000006298a4a7 ((console_sem).lock){-.-.}, at: down_trylock+0x13/0x70
kernel/locking/semaphore.c:136
but task is already holding lock:
0000000018a38b75 (hrtimer_bases.lock){-.-.}, at:
lock_hrtimer_base.isra.18+0x75/0x130 kernel/time/hrtimer.c:174
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #4 (hrtimer_bases.lock){-.-.}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
lock_hrtimer_base.isra.18+0x75/0x130 kernel/time/hrtimer.c:174
hrtimer_start_range_ns+0x128/0xd20 kernel/time/hrtimer.c:1113
hrtimer_start_expires include/linux/hrtimer.h:412 [inline]
start_rt_bandwidth kernel/sched/rt.c:68 [inline]
inc_rt_group kernel/sched/rt.c:1147 [inline]
inc_rt_tasks kernel/sched/rt.c:1191 [inline]
__enqueue_rt_entity kernel/sched/rt.c:1261 [inline]
enqueue_rt_entity kernel/sched/rt.c:1305 [inline]
enqueue_task_rt+0x96a/0xfd0 kernel/sched/rt.c:1335
enqueue_task+0xa2/0x1d0 kernel/sched/core.c:750
__sched_setscheduler+0xe80/0x20b0 kernel/sched/core.c:4365
_sched_setscheduler+0x20c/0x370 kernel/sched/core.c:4402
sched_setscheduler+0xe/0x10 kernel/sched/core.c:4417
watchdog_set_prio kernel/watchdog.c:455 [inline]
watchdog_enable+0x12d/0x1a0 kernel/watchdog.c:477
smpboot_thread_fn+0x4c0/0x870 kernel/smpboot.c:145
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
-> #3 (&rt_b->rt_runtime_lock){-.-.}:
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:144
start_rt_bandwidth kernel/sched/rt.c:56 [inline]
inc_rt_group kernel/sched/rt.c:1147 [inline]
inc_rt_tasks kernel/sched/rt.c:1191 [inline]
__enqueue_rt_entity kernel/sched/rt.c:1261 [inline]
enqueue_rt_entity kernel/sched/rt.c:1305 [inline]
enqueue_task_rt+0x618/0xfd0 kernel/sched/rt.c:1335
enqueue_task+0xa2/0x1d0 kernel/sched/core.c:750
__sched_setscheduler+0xe80/0x20b0 kernel/sched/core.c:4365
_sched_setscheduler+0x20c/0x370 kernel/sched/core.c:4402
sched_setscheduler+0xe/0x10 kernel/sched/core.c:4417
watchdog_set_prio kernel/watchdog.c:455 [inline]
watchdog_enable+0x12d/0x1a0 kernel/watchdog.c:477
smpboot_thread_fn+0x4c0/0x870 kernel/smpboot.c:145
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
-> #2 (&rq->lock){-.-.}:
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:144
rq_lock kernel/sched/sched.h:1812 [inline]
task_fork_fair+0x93/0x680 kernel/sched/fair.c:9952
sched_fork+0x446/0xb40 kernel/sched/core.c:2381
copy_process.part.39+0x1bf5/0x70b0 kernel/fork.c:1796
copy_process kernel/fork.c:1639 [inline]
_do_fork+0x291/0x12a0 kernel/fork.c:2122
kernel_thread+0x34/0x40 kernel/fork.c:2181
rest_init+0x22/0xe4 init/main.c:408
start_kernel+0x90e/0x949 init/main.c:738
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:452
x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:433
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
-> #1 (&p->pi_lock){-.-.}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
try_to_wake_up+0xd2/0x12a0 kernel/sched/core.c:1985
wake_up_process+0x10/0x20 kernel/sched/core.c:2148
__up.isra.1+0x1c0/0x2a0 kernel/locking/semaphore.c:262
up+0x13c/0x1c0 kernel/locking/semaphore.c:187
__up_console_sem+0xbe/0x1b0 kernel/printk/printk.c:242
console_unlock+0x7a2/0x10b0 kernel/printk/printk.c:2411
vprintk_emit+0x6c6/0xdf0 kernel/printk/printk.c:1907
vprintk_default+0x28/0x30 kernel/printk/printk.c:1948
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:382
printk+0xa7/0xcf kernel/printk/printk.c:1981
load_umh+0x51/0xbd net/bpfilter/bpfilter_kern.c:98
do_one_initcall+0x127/0x913 init/main.c:884
do_initcall_level init/main.c:952 [inline]
do_initcalls init/main.c:960 [inline]
do_basic_setup init/main.c:978 [inline]
kernel_init_freeable+0x49b/0x58e init/main.c:1135
kernel_init+0x11/0x1b3 init/main.c:1061
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
-> #0 ((console_sem).lock){-.-.}:
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
down_trylock+0x13/0x70 kernel/locking/semaphore.c:136
__down_trylock_console_sem+0xae/0x200 kernel/printk/printk.c:225
console_trylock+0x15/0xa0 kernel/printk/printk.c:2230
console_trylock_spinning kernel/printk/printk.c:1643 [inline]
vprintk_emit+0x6ad/0xdf0 kernel/printk/printk.c:1906
vprintk_default+0x28/0x30 kernel/printk/printk.c:1948
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:382
printk+0xa7/0xcf kernel/printk/printk.c:1981
__warn_printk+0x8c/0xe0 kernel/panic.c:590
debug_print_object+0x16a/0x210 lib/debugobjects.c:326
debug_object_activate+0x359/0x690 lib/debugobjects.c:513
debug_hrtimer_activate kernel/time/hrtimer.c:416 [inline]
debug_activate kernel/time/hrtimer.c:465 [inline]
enqueue_hrtimer+0x9e/0x540 kernel/time/hrtimer.c:954
__hrtimer_start_range_ns kernel/time/hrtimer.c:1089 [inline]
hrtimer_start_range_ns+0x616/0xd20 kernel/time/hrtimer.c:1115
hrtimer_start include/linux/hrtimer.h:398 [inline]
bcm_tx_start_timer+0x11d/0x1b0 net/can/bcm.c:361
bcm_tx_timeout_tsklet+0x1ab/0x4b0 net/can/bcm.c:392
tasklet_action_common.isra.19+0x26f/0x720 kernel/softirq.c:522
tasklet_action+0x1d/0x20 kernel/softirq.c:540
__do_softirq+0x2e8/0xb17 kernel/softirq.c:292
run_ksoftirqd+0x86/0x100 kernel/softirq.c:653
smpboot_thread_fn+0x417/0x870 kernel/smpboot.c:164
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
other info that might help us debug this:
Chain exists of:
(console_sem).lock --> &rt_b->rt_runtime_lock --> hrtimer_bases.lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(hrtimer_bases.lock);
lock(&rt_b->rt_runtime_lock);
lock(hrtimer_bases.lock);
lock((console_sem).lock);
*** DEADLOCK ***
1 lock held by ksoftirqd/1/18:
#0: 0000000018a38b75 (hrtimer_bases.lock){-.-.}, at:
lock_hrtimer_base.isra.18+0x75/0x130 kernel/time/hrtimer.c:174
stack backtrace:
CPU: 1 PID: 18 Comm: ksoftirqd/1 Not tainted 4.18.0-rc7+ #170
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_circular_bug.isra.36.cold.57+0x1bd/0x27d
kernel/locking/lockdep.c:1227
check_prev_add kernel/locking/lockdep.c:1867 [inline]
check_prevs_add kernel/locking/lockdep.c:1980 [inline]
validate_chain kernel/locking/lockdep.c:2421 [inline]
__lock_acquire+0x3449/0x5020 kernel/locking/lockdep.c:3435
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
down_trylock+0x13/0x70 kernel/locking/semaphore.c:136
__down_trylock_console_sem+0xae/0x200 kernel/printk/printk.c:225
console_trylock+0x15/0xa0 kernel/printk/printk.c:2230
console_trylock_spinning kernel/printk/printk.c:1643 [inline]
vprintk_emit+0x6ad/0xdf0 kernel/printk/printk.c:1906
vprintk_default+0x28/0x30 kernel/printk/printk.c:1948
vprintk_func+0x7a/0xe7 kernel/printk/printk_safe.c:382
printk+0xa7/0xcf kernel/printk/printk.c:1981
__warn_printk+0x8c/0xe0 kernel/panic.c:590
debug_print_object+0x16a/0x210 lib/debugobjects.c:326
debug_object_activate+0x359/0x690 lib/debugobjects.c:513
debug_hrtimer_activate kernel/time/hrtimer.c:416 [inline]
debug_activate kernel/time/hrtimer.c:465 [inline]
enqueue_hrtimer+0x9e/0x540 kernel/time/hrtimer.c:954
__hrtimer_start_range_ns kernel/time/hrtimer.c:1089 [inline]
hrtimer_start_range_ns+0x616/0xd20 kernel/time/hrtimer.c:1115
hrtimer_start include/linux/hrtimer.h:398 [inline]
bcm_tx_start_timer+0x11d/0x1b0 net/can/bcm.c:361
bcm_tx_timeout_tsklet+0x1ab/0x4b0 net/can/bcm.c:392
tasklet_action_common.isra.19+0x26f/0x720 kernel/softirq.c:522
tasklet_action+0x1d/0x20 kernel/softirq.c:540
__do_softirq+0x2e8/0xb17 kernel/softirq.c:292
run_ksoftirqd+0x86/0x100 kernel/softirq.c:653
smpboot_thread_fn+0x417/0x870 kernel/smpboot.c:164
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
Shutting down cpus with NMI
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
* KASAN: use-after-free Read in rtnetlink_put_metrics
From: syzbot @ 2018-07-31 12:31 UTC (permalink / raw)
To: christian.brauner, davem, dsahern, fw, jbenc, ktkhai,
linux-kernel, lucien.xin, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 61f4b23769f0 netlink: Don't shift with UB on nlk->ngroups
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=14a9de58400000
kernel config: https://syzkaller.appspot.com/x/.config?x=ffb4428fdc82f93b
dashboard link: https://syzkaller.appspot.com/bug?extid=41f9c04b50ef70c66947
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+41f9c04b50ef70c66947@syzkaller.appspotmail.com
TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending
cookies. Check SNMP counters.
==================================================================
BUG: KASAN: use-after-free in rtnetlink_put_metrics+0x621/0x690
net/core/rtnetlink.c:754
Read of size 4 at addr ffff8801b3cd8b00 by task udevd/2613
CPU: 0 PID: 2613 Comm: udevd Not tainted 4.18.0-rc6+ #34
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+0x1c9/0x2b4 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_load4_noabort+0x14/0x20 mm/kasan/report.c:432
rtnetlink_put_metrics+0x621/0x690 net/core/rtnetlink.c:754
rt6_fill_node+0x7d9/0x1540 net/ipv6/route.c:4753
inet6_rt_notify+0x161/0x2c0 net/ipv6/route.c:4985
fib6_del_route net/ipv6/ip6_fib.c:1788 [inline]
fib6_del+0xf4d/0x1310 net/ipv6/ip6_fib.c:1815
fib6_clean_node+0x3ee/0x5e0 net/ipv6/ip6_fib.c:1976
fib6_walk_continue+0x4b1/0x8e0 net/ipv6/ip6_fib.c:1899
fib6_walk+0x95/0xf0 net/ipv6/ip6_fib.c:1947
fib6_clean_tree+0x1ea/0x360 net/ipv6/ip6_fib.c:2024
__fib6_clean_all+0x21c/0x420 net/ipv6/ip6_fib.c:2040
fib6_clean_all net/ipv6/ip6_fib.c:2051 [inline]
fib6_run_gc+0x182/0x3d0 net/ipv6/ip6_fib.c:2107
fib6_gc_timer_cb+0x20/0x30 net/ipv6/ip6_fib.c:2124
call_timer_fn+0x242/0x970 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0x7a6/0xc70 kernel/time/timer.c:1666
run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
__do_softirq+0x2e8/0xb17 kernel/softirq.c:292
invoke_softirq kernel/softirq.c:372 [inline]
irq_exit+0x1d4/0x210 kernel/softirq.c:412
exiting_irq arch/x86/include/asm/apic.h:527 [inline]
smp_apic_timer_interrupt+0x186/0x730 arch/x86/kernel/apic/apic.c:1052
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
</IRQ>
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783
[inline]
RIP: 0010:qlink_free mm/kasan/quarantine.c:150 [inline]
RIP: 0010:qlist_free_all+0xf8/0x160 mm/kasan/quarantine.c:166
Code: c7 40 10 00 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8
57 b8 a4 ff 48 83 3d 67 b4 37 06 00 74 56 48 89 df 57 9d <0f> 1f 44 00 00
eb af ba 00 00 00 80 48 01 c2 72 43 48 b9 00 00 00
RSP: 0018:ffff8801b54a7b08 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000007 RBX: 0000000000000286 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff8801b5498a38 RDI: 0000000000000286
RBP: ffff8801b54a7b40 R08: ffff8801b5498a38 R09: 0000000000000006
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff8801dad85dc0 R14: ffff8801b37ace00 R15: ffffffff87f1b0a0
quarantine_reduce+0x163/0x1a0 mm/kasan/quarantine.c:259
kasan_kmalloc+0x99/0xe0 mm/kasan/kasan.c:538
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
slab_post_alloc_hook mm/slab.h:444 [inline]
slab_alloc mm/slab.c:3392 [inline]
kmem_cache_alloc+0x11b/0x760 mm/slab.c:3552
getname_flags+0xd0/0x5a0 fs/namei.c:140
user_path_at_empty+0x2d/0x50 fs/namei.c:2584
do_readlinkat+0x14b/0x400 fs/stat.c:394
__do_sys_readlink fs/stat.c:427 [inline]
__se_sys_readlink fs/stat.c:424 [inline]
__x64_sys_readlink+0x78/0xb0 fs/stat.c:424
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7efd8271b577
Code: f0 ff ff 77 02 f3 c3 48 8b 15 bd 38 2b 00 f7 d8 64 89 02 83 c8 ff c3
90 90 90 90 90 90 90 90 90 90 90 90 b8 59 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 73 01 c3 48 8b 0d 91 38 2b 00 31 d2 48 29 c2 64
RSP: 002b:00007ffe27d23688 EFLAGS: 00000246 ORIG_RAX: 0000000000000059
RAX: ffffffffffffffda RBX: 00000000021de250 RCX: 00007efd8271b577
RDX: 0000000000000400 RSI: 00007ffe27d23690 RDI: 00007ffe27d23b70
RBP: 00007ffe27d243b0 R08: 00007ffe27d243b0 R09: 00007efd8276fdc0
R10: 7665642f7379732f R11: 0000000000000246 R12: 00007ffe27d23b70
R13: 0000000000000400 R14: 00000000021de250 R15: 00000000021e3e10
Allocated by task 8953:
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
kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620
kmalloc include/linux/slab.h:513 [inline]
kzalloc include/linux/slab.h:707 [inline]
fib6_metric_set+0x163/0x2c0 net/ipv6/ip6_fib.c:645
fib6_add_rt2node+0xe36/0x27f0 net/ipv6/ip6_fib.c:1000
fib6_add+0xaae/0x14d0 net/ipv6/ip6_fib.c:1308
__ip6_ins_rt+0x54/0x80 net/ipv6/route.c:1163
ip6_route_add+0x6d/0xc0 net/ipv6/route.c:3171
addrconf_prefix_route.isra.48+0x51d/0x720 net/ipv6/addrconf.c:2347
inet6_addr_modify net/ipv6/addrconf.c:4627 [inline]
inet6_rtm_newaddr+0x112e/0x1b50 net/ipv6/addrconf.c:4743
rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4665
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2453
rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4683
netlink_unicast_kernel net/netlink/af_netlink.c:1315 [inline]
netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1341
netlink_sendmsg+0xa18/0xfd0 net/netlink/af_netlink.c:1906
sock_sendmsg_nosec net/socket.c:642 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:652
___sys_sendmsg+0x7fd/0x930 net/socket.c:2126
__sys_sendmsg+0x11d/0x290 net/socket.c:2164
__do_sys_sendmsg net/socket.c:2173 [inline]
__se_sys_sendmsg net/socket.c:2171 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2171
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 2613:
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
fib6_metrics_release+0x77/0x90 net/ipv6/ip6_fib.c:179
fib6_drop_pcpu_from net/ipv6/ip6_fib.c:899 [inline]
fib6_purge_rt+0x5ec/0x7f0 net/ipv6/ip6_fib.c:934
fib6_del_route net/ipv6/ip6_fib.c:1784 [inline]
fib6_del+0xc11/0x1310 net/ipv6/ip6_fib.c:1815
fib6_clean_node+0x3ee/0x5e0 net/ipv6/ip6_fib.c:1976
fib6_walk_continue+0x4b1/0x8e0 net/ipv6/ip6_fib.c:1899
fib6_walk+0x95/0xf0 net/ipv6/ip6_fib.c:1947
fib6_clean_tree+0x1ea/0x360 net/ipv6/ip6_fib.c:2024
__fib6_clean_all+0x21c/0x420 net/ipv6/ip6_fib.c:2040
fib6_clean_all net/ipv6/ip6_fib.c:2051 [inline]
fib6_run_gc+0x182/0x3d0 net/ipv6/ip6_fib.c:2107
fib6_gc_timer_cb+0x20/0x30 net/ipv6/ip6_fib.c:2124
call_timer_fn+0x242/0x970 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0x7a6/0xc70 kernel/time/timer.c:1666
run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
__do_softirq+0x2e8/0xb17 kernel/softirq.c:292
The buggy address belongs to the object at ffff8801b3cd8b00
which belongs to the cache kmalloc-96 of size 96
The buggy address is located 0 bytes inside of
96-byte region [ffff8801b3cd8b00, ffff8801b3cd8b60)
The buggy address belongs to the page:
page:ffffea0006cf3600 count:1 mapcount:0 mapping:ffff8801dac004c0 index:0x0
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffffea0006a6f3c8 ffffea0007018608 ffff8801dac004c0
raw: 0000000000000000 ffff8801b3cd8000 0000000100000020 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801b3cd8a00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff8801b3cd8a80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ffff8801b3cd8b00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
^
ffff8801b3cd8b80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff8801b3cd8c00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
==================================================================
---
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: KASAN: use-after-free Read in rtnetlink_put_metrics
From: Eric Dumazet @ 2018-07-31 12:41 UTC (permalink / raw)
To: syzbot, christian.brauner, davem, dsahern, fw, jbenc, ktkhai,
linux-kernel, lucien.xin, netdev, syzkaller-bugs, Sabrina Dubroca
In-Reply-To: <0000000000004fe2be05724ac084@google.com>
On 07/31/2018 05:31 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 61f4b23769f0 netlink: Don't shift with UB on nlk->ngroups
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=14a9de58400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=ffb4428fdc82f93b
> dashboard link: https://syzkaller.appspot.com/bug?extid=41f9c04b50ef70c66947
> 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+41f9c04b50ef70c66947@syzkaller.appspotmail.com
>
> TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending cookies. Check SNMP counters.
> ==================================================================
> BUG: KASAN: use-after-free in rtnetlink_put_metrics+0x621/0x690 net/core/rtnetlink.c:754
> Read of size 4 at addr ffff8801b3cd8b00 by task udevd/2613
>
> CPU: 0 PID: 2613 Comm: udevd Not tainted 4.18.0-rc6+ #34
> 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+0x1c9/0x2b4 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_load4_noabort+0x14/0x20 mm/kasan/report.c:432
> rtnetlink_put_metrics+0x621/0x690 net/core/rtnetlink.c:754
> rt6_fill_node+0x7d9/0x1540 net/ipv6/route.c:4753
> inet6_rt_notify+0x161/0x2c0 net/ipv6/route.c:4985
> fib6_del_route net/ipv6/ip6_fib.c:1788 [inline]
> fib6_del+0xf4d/0x1310 net/ipv6/ip6_fib.c:1815
> fib6_clean_node+0x3ee/0x5e0 net/ipv6/ip6_fib.c:1976
> fib6_walk_continue+0x4b1/0x8e0 net/ipv6/ip6_fib.c:1899
> fib6_walk+0x95/0xf0 net/ipv6/ip6_fib.c:1947
> fib6_clean_tree+0x1ea/0x360 net/ipv6/ip6_fib.c:2024
> __fib6_clean_all+0x21c/0x420 net/ipv6/ip6_fib.c:2040
> fib6_clean_all net/ipv6/ip6_fib.c:2051 [inline]
> fib6_run_gc+0x182/0x3d0 net/ipv6/ip6_fib.c:2107
> fib6_gc_timer_cb+0x20/0x30 net/ipv6/ip6_fib.c:2124
> call_timer_fn+0x242/0x970 kernel/time/timer.c:1326
> expire_timers kernel/time/timer.c:1363 [inline]
> __run_timers+0x7a6/0xc70 kernel/time/timer.c:1666
> run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
> __do_softirq+0x2e8/0xb17 kernel/softirq.c:292
> invoke_softirq kernel/softirq.c:372 [inline]
> irq_exit+0x1d4/0x210 kernel/softirq.c:412
> exiting_irq arch/x86/include/asm/apic.h:527 [inline]
> smp_apic_timer_interrupt+0x186/0x730 arch/x86/kernel/apic/apic.c:1052
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
> </IRQ>
> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 [inline]
> RIP: 0010:qlink_free mm/kasan/quarantine.c:150 [inline]
> RIP: 0010:qlist_free_all+0xf8/0x160 mm/kasan/quarantine.c:166
> Code: c7 40 10 00 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 57 b8 a4 ff 48 83 3d 67 b4 37 06 00 74 56 48 89 df 57 9d <0f> 1f 44 00 00 eb af ba 00 00 00 80 48 01 c2 72 43 48 b9 00 00 00
> RSP: 0018:ffff8801b54a7b08 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
> RAX: 0000000000000007 RBX: 0000000000000286 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffff8801b5498a38 RDI: 0000000000000286
> RBP: ffff8801b54a7b40 R08: ffff8801b5498a38 R09: 0000000000000006
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff8801dad85dc0 R14: ffff8801b37ace00 R15: ffffffff87f1b0a0
> quarantine_reduce+0x163/0x1a0 mm/kasan/quarantine.c:259
> kasan_kmalloc+0x99/0xe0 mm/kasan/kasan.c:538
> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
> slab_post_alloc_hook mm/slab.h:444 [inline]
> slab_alloc mm/slab.c:3392 [inline]
> kmem_cache_alloc+0x11b/0x760 mm/slab.c:3552
> getname_flags+0xd0/0x5a0 fs/namei.c:140
> user_path_at_empty+0x2d/0x50 fs/namei.c:2584
> do_readlinkat+0x14b/0x400 fs/stat.c:394
> __do_sys_readlink fs/stat.c:427 [inline]
> __se_sys_readlink fs/stat.c:424 [inline]
> __x64_sys_readlink+0x78/0xb0 fs/stat.c:424
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x7efd8271b577
> Code: f0 ff ff 77 02 f3 c3 48 8b 15 bd 38 2b 00 f7 d8 64 89 02 83 c8 ff c3 90 90 90 90 90 90 90 90 90 90 90 90 b8 59 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 91 38 2b 00 31 d2 48 29 c2 64
> RSP: 002b:00007ffe27d23688 EFLAGS: 00000246 ORIG_RAX: 0000000000000059
> RAX: ffffffffffffffda RBX: 00000000021de250 RCX: 00007efd8271b577
> RDX: 0000000000000400 RSI: 00007ffe27d23690 RDI: 00007ffe27d23b70
> RBP: 00007ffe27d243b0 R08: 00007ffe27d243b0 R09: 00007efd8276fdc0
> R10: 7665642f7379732f R11: 0000000000000246 R12: 00007ffe27d23b70
> R13: 0000000000000400 R14: 00000000021de250 R15: 00000000021e3e10
>
> Allocated by task 8953:
> 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
> kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620
> kmalloc include/linux/slab.h:513 [inline]
> kzalloc include/linux/slab.h:707 [inline]
> fib6_metric_set+0x163/0x2c0 net/ipv6/ip6_fib.c:645
> fib6_add_rt2node+0xe36/0x27f0 net/ipv6/ip6_fib.c:1000
> fib6_add+0xaae/0x14d0 net/ipv6/ip6_fib.c:1308
> __ip6_ins_rt+0x54/0x80 net/ipv6/route.c:1163
> ip6_route_add+0x6d/0xc0 net/ipv6/route.c:3171
> addrconf_prefix_route.isra.48+0x51d/0x720 net/ipv6/addrconf.c:2347
> inet6_addr_modify net/ipv6/addrconf.c:4627 [inline]
> inet6_rtm_newaddr+0x112e/0x1b50 net/ipv6/addrconf.c:4743
> rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4665
> netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2453
> rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4683
> netlink_unicast_kernel net/netlink/af_netlink.c:1315 [inline]
> netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1341
> netlink_sendmsg+0xa18/0xfd0 net/netlink/af_netlink.c:1906
> sock_sendmsg_nosec net/socket.c:642 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:652
> ___sys_sendmsg+0x7fd/0x930 net/socket.c:2126
> __sys_sendmsg+0x11d/0x290 net/socket.c:2164
> __do_sys_sendmsg net/socket.c:2173 [inline]
> __se_sys_sendmsg net/socket.c:2171 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2171
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 2613:
> 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
> fib6_metrics_release+0x77/0x90 net/ipv6/ip6_fib.c:179
> fib6_drop_pcpu_from net/ipv6/ip6_fib.c:899 [inline]
> fib6_purge_rt+0x5ec/0x7f0 net/ipv6/ip6_fib.c:934
> fib6_del_route net/ipv6/ip6_fib.c:1784 [inline]
> fib6_del+0xc11/0x1310 net/ipv6/ip6_fib.c:1815
> fib6_clean_node+0x3ee/0x5e0 net/ipv6/ip6_fib.c:1976
> fib6_walk_continue+0x4b1/0x8e0 net/ipv6/ip6_fib.c:1899
> fib6_walk+0x95/0xf0 net/ipv6/ip6_fib.c:1947
> fib6_clean_tree+0x1ea/0x360 net/ipv6/ip6_fib.c:2024
> __fib6_clean_all+0x21c/0x420 net/ipv6/ip6_fib.c:2040
> fib6_clean_all net/ipv6/ip6_fib.c:2051 [inline]
> fib6_run_gc+0x182/0x3d0 net/ipv6/ip6_fib.c:2107
> fib6_gc_timer_cb+0x20/0x30 net/ipv6/ip6_fib.c:2124
> call_timer_fn+0x242/0x970 kernel/time/timer.c:1326
> expire_timers kernel/time/timer.c:1363 [inline]
> __run_timers+0x7a6/0xc70 kernel/time/timer.c:1666
> run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
> __do_softirq+0x2e8/0xb17 kernel/softirq.c:292
>
> The buggy address belongs to the object at ffff8801b3cd8b00
> which belongs to the cache kmalloc-96 of size 96
> The buggy address is located 0 bytes inside of
> 96-byte region [ffff8801b3cd8b00, ffff8801b3cd8b60)
> The buggy address belongs to the page:
> page:ffffea0006cf3600 count:1 mapcount:0 mapping:ffff8801dac004c0 index:0x0
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffffea0006a6f3c8 ffffea0007018608 ffff8801dac004c0
> raw: 0000000000000000 ffff8801b3cd8000 0000000100000020 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801b3cd8a00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ffff8801b3cd8a80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
>> ffff8801b3cd8b00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ^
> ffff8801b3cd8b80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ffff8801b3cd8c00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ==================================================================
>
>
> ---
> 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.
Probably also caused by :
commit df18b50448fab1dff093731dfd0e25e77e1afcd1
Author: Sabrina Dubroca <sd@queasysnail.net>
Date: Mon Jul 30 16:23:10 2018 +0200
net/ipv6: fix metrics leak
^ permalink raw reply
* Re: [net-next 10/16] net/mlx5: Support PCIe buffer congestion handling via Devlink
From: Bjorn Helgaas @ 2018-07-31 11:06 UTC (permalink / raw)
To: Alexander Duyck
Cc: Moshe Shemesh, Jiri Pirko, Jakub Kicinski, Eran Ben Elisha,
Saeed Mahameed, David S. Miller, netdev@vger.kernel.org,
linux-pci
In-Reply-To: <CAKgT0Uc2jTtpGC+q_THWQK33csrOW2jfuGRix387mmJExSSJaA@mail.gmail.com>
On Mon, Jul 30, 2018 at 08:19:50PM -0700, Alexander Duyck wrote:
> On Mon, Jul 30, 2018 at 7:33 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Mon, Jul 30, 2018 at 08:02:48AM -0700, Alexander Duyck wrote:
> >> On Mon, Jul 30, 2018 at 7:07 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> >> > On Sun, Jul 29, 2018 at 03:00:28PM -0700, Alexander Duyck wrote:
> >> >> On Sun, Jul 29, 2018 at 2:23 AM, Moshe Shemesh <moshes20.il@gmail.com> wrote:
> >> >> > On Sat, Jul 28, 2018 at 7:06 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> >> >> >> On Thu, Jul 26, 2018 at 07:00:20AM -0700, Alexander Duyck wrote:
> >> >> >> > On Thu, Jul 26, 2018 at 12:14 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> >> >> >> > > Thu, Jul 26, 2018 at 02:43:59AM CEST, jakub.kicinski@netronome.com
> >> >> >> > > wrote:
> >> >> >> > >>On Wed, 25 Jul 2018 08:23:26 -0700, Alexander Duyck wrote:
> >> >> >> > >>> On Wed, Jul 25, 2018 at 5:31 AM, Eran Ben Elisha wrote:
> >> >> >> > >>> > On 7/24/2018 10:51 PM, Jakub Kicinski wrote:
> >> >> >> > >>> >>>> The devlink params haven't been upstream even for a full cycle
> >> >> >> > >>> >>>> and
> >> >> >> > >>> >>>> already you guys are starting to use them to configure standard
> >> >> >> > >>> >>>> features like queuing.
> >> >> >> > >>> >>>
> >> >> >> > >>> >>> We developed the devlink params in order to support non-standard
> >> >> >> > >>> >>> configuration only. And for non-standard, there are generic and
> >> >> >> > >>> >>> vendor
> >> >> >> > >>> >>> specific options.
> >> >> >> > >>> >>
> >> >> >> > >>> >> I thought it was developed for performing non-standard and
> >> >> >> > >>> >> possibly
> >> >> >> > >>> >> vendor specific configuration. Look at DEVLINK_PARAM_GENERIC_*
> >> >> >> > >>> >> for
> >> >> >> > >>> >> examples of well justified generic options for which we have no
> >> >> >> > >>> >> other API. The vendor mlx4 options look fairly vendor specific
> >> >> >> > >>> >> if you
> >> >> >> > >>> >> ask me, too.
> >> >> >> > >>> >>
> >> >> >> > >>> >> Configuring queuing has an API. The question is it acceptable to
> >> >> >> > >>> >> enter
> >> >> >> > >>> >> into the risky territory of controlling offloads via devlink
> >> >> >> > >>> >> parameters
> >> >> >> > >>> >> or would we rather make vendors take the time and effort to model
> >> >> >> > >>> >> things to (a subset) of existing APIs. The HW never fits the
> >> >> >> > >>> >> APIs
> >> >> >> > >>> >> perfectly.
> >> >> >> > >>> >
> >> >> >> > >>> > I understand what you meant here, I would like to highlight that
> >> >> >> > >>> > this
> >> >> >> > >>> > mechanism was not meant to handle SRIOV, Representors, etc.
> >> >> >> > >>> > The vendor specific configuration suggested here is to handle a
> >> >> >> > >>> > congestion
> >> >> >> > >>> > state in Multi Host environment (which includes PF and multiple
> >> >> >> > >>> > VFs per
> >> >> >> > >>> > host), where one host is not aware to the other hosts, and each is
> >> >> >> > >>> > running
> >> >> >> > >>> > on its own pci/driver. It is a device working mode configuration.
> >> >> >> > >>> >
> >> >> >> > >>> > This couldn't fit into any existing API, thus creating this
> >> >> >> > >>> > vendor specific
> >> >> >> > >>> > unique API is needed.
> >> >> >> > >>>
> >> >> >> > >>> If we are just going to start creating devlink interfaces in for
> >> >> >> > >>> every
> >> >> >> > >>> one-off option a device wants to add why did we even bother with
> >> >> >> > >>> trying to prevent drivers from using sysfs? This just feels like we
> >> >> >> > >>> are back to the same arguments we had back in the day with it.
> >> >> >> > >>>
> >> >> >> > >>> I feel like the bigger question here is if devlink is how we are
> >> >> >> > >>> going
> >> >> >> > >>> to deal with all PCIe related features going forward, or should we
> >> >> >> > >>> start looking at creating a new interface/tool for PCI/PCIe related
> >> >> >> > >>> features? My concern is that we have already had features such as
> >> >> >> > >>> DMA
> >> >> >> > >>> Coalescing that didn't really fit into anything and now we are
> >> >> >> > >>> starting to see other things related to DMA and PCIe bus credits.
> >> >> >> > >>> I'm
> >> >> >> > >>> wondering if we shouldn't start looking at a tool/interface to
> >> >> >> > >>> configure all the PCIe related features such as interrupts, error
> >> >> >> > >>> reporting, DMA configuration, power management, etc. Maybe we could
> >> >> >> > >>> even look at sharing it across subsystems and include things like
> >> >> >> > >>> storage, graphics, and other subsystems in the conversation.
> >> >> >> > >>
> >> >> >> > >>Agreed, for actual PCIe configuration (i.e. not ECN marking) we do
> >> >> >> > >> need
> >> >> >> > >>to build up an API. Sharing it across subsystems would be very cool!
> >> >> >>
> >> >> >> I read the thread (starting at [1], for anybody else coming in late)
> >> >> >> and I see this has something to do with "configuring outbound PCIe
> >> >> >> buffers", but I haven't seen the connection to PCIe protocol or
> >> >> >> features, i.e., I can't connect this to anything in the PCIe spec.
> >> >> >>
> >> >> >> Can somebody help me understand how the PCI core is relevant? If
> >> >> >> there's some connection with a feature defined by PCIe, or if it
> >> >> >> affects the PCIe transaction protocol somehow, I'm definitely
> >> >> >> interested in this. But if this only affects the data transferred
> >> >> >> over PCIe, i.e., the data payloads of PCIe TLP packets, then I'm not
> >> >> >> sure why the PCI core should care.
> >> >> >
> >> >> > As you wrote, this is not a PCIe feature or affects the PCIe transaction
> >> >> > protocol.
> >> >> >
> >> >> > Actually, due to hardware limitation in current device, we have enabled a
> >> >> > workaround in hardware.
> >> >> >
> >> >> > This mode is proprietary and not relevant to other PCIe devices, thus is set
> >> >> > using driver-specific parameter in devlink
> >> >>
> >> >> Essentially what this feature is doing is communicating the need for
> >> >> PCIe back-pressure to the network fabric. So as the buffers on the
> >> >> device start to fill because the device isn't able to get back PCIe
> >> >> credits fast enough it will then start to send congestion
> >> >> notifications to the network stack itself if I understand this
> >> >> correctly.
> >> >
> >> > This sounds like a hook that allows the device to tell its driver
> >> > about PCIe flow control credits, and the driver can pass that on to
> >> > the network stack. IIUC, that would be a device-specific feature
> >> > outside the scope of the PCI core.
> >> >
> >> >> For now there are no major conflicts, but when we start getting into
> >> >> stuff like PCIe DMA coalescing, and on a more general basis just PCIe
> >> >> active state power management that is going to start making things
> >> >> more complicated going forward.
> >> >
> >> > We do support ASPM already in the PCI core, and we do have the
> >> > pci_disable_link_state() interface, which is currently the only way
> >> > drivers can influence it. There are several drivers that do their own
> >> > ASPM configuration, but this is not safe because it's not coordinated
> >> > with what the PCI core does. If/when drivers need more control, we
> >> > should enhance the PCI core interfaces.
> >>
> >> This is kind of what I was getting at. It would be useful to have an
> >> interface of some sort so that drivers get notified when a user is
> >> making changes to configuration space and I don't know if anything
> >> like that exists now.
> >
> > You mean something like this?
> >
> > - driver registers a callback with PCI core
> > - user runs setpci, which writes PCI config space via sysfs
> > - kernel hook in pci_write_config() notices write and calls driver
> > callback
> > - driver callback receives config address and data written
> > - driver parses PCI capability lists to identify register
> >
> > Nothing like that exists today, and this is not what I had in mind by
> > "enhance the PCI core interfaces". I'm not sure what the utility of
> > this is (but I'm not a networking guy by any means).
>
> Well in general I have been wondering if setpci is really the cleanest
> way to do any of this. I have found it can be a fast way to really
> mess things up. For example using setpci to trigger an FLR is a fast
> way to cripple an interface. I recall using that approach when testing
> the fm10k driver to deal with surprise resets.
>
> The problem is setpci is REALLY powerful. It lets you change a ton
> that can impact the driver, and many drivers just read the config
> space at the probe function and assume it is static (which in most
> cases it is). That is why I was thinking as a small step it might be
> useful to have the notifications delivered to the driver if it is
> registered on the interface so it could prepare or clean-up after a
> change to the PCI configuration space.
Yep, setpci is very powerful. I doubt it's worth having drivers try
to react, just because setpci can do completely arbitrary things, many
of which are not recoverable even in principle. But I do think we
should make it taint the kernel so we have a clue when things go
wrong.
> > I think it's a bad idea for drivers to directly write config space.
> > It would be much better to provide a PCI core interface so we can
> > implement things once and coordinate things that need to be
> > coordinated.
>
> I agree with that.
>
> >> > I don't know what PCIe DMA coalescing means, so I can't comment on
> >> > that.
> >>
> >> There are devices, specifically network devices, that will hold off on
> >> switching between either L0s or L1 and L0 by deferring DMA operations.
> >> Basically the idea is supposed to be to hold off bringing the link up
> >> for as long as possible in order to maximize power savings for the
> >> ASPM state. This is something that has come up in the past, and I
> >> don't know if there has been any interface determined for how to
> >> handle this sort of configuration. Most of it occurs through MMIO.
> >
> > The device can certainly delay L0s or L1 exit if it wants to. If
> > there are knobs to control this, e.g., how long it can defer a DMA, it
> > makes sense that they would be device-specific and in MMIO space. The
> > PCI core can't be involved in that because in general it knows nothing
> > about the contents of MMIO BARs. Presumably those knobs would work
> > within the framework of ASPM as defined by the PCIe spec, e.g., if we
> > disable ASPM, the knobs would do nothing because there is no L0s or L1
> > at all.
> >
> > That's not to say that device designers couldn't get together and
> > define a common model for such knobs that puts them at well-known
> > offsets in well-known BARs. All I'm saying is that this sounds like
> > it's currently outside the realm of the PCI specs and the PCI core.
>
> Some of this was already handled in LTR and OBFF. I think the DMA
> coalescing was meant to work either with those, or optionally on its
> own. As far as being ASPM dependent or not I don't think it really
> cared all that much other than knowing if ASPM was enabled and how
> long it takes for a given device to come out of either of those
> states. The general idea with DMA coalescing was to try and save power
> on the CPU and then possibly the PCIe link if the value was set high
> enough and ASPM was enabled.
>
> Anyway we have kind of gotten off into a tangent as I was just citing
> something that might end up having an interaction with a feature such
> as notifying the stack that the Rx buffer on a given device has become
> congested.
>
> >> >> I assume the devices we are talking about supporting this new feature
> >> >> on either don't deal with ASPM or assume a quick turnaround to get out
> >> >> of the lower power states? Otherwise that would definitely cause some
> >> >> back-pressure buildups that would hurt performance.
> >> >
> >> > Devices can communicate the ASPM exit latency they can tolerate via
> >> > the Device Capabilities register (PCIe r4.0, sec 76.5.3.3). Linux
> >> > should be configuring ASPM to respect those device requirements.
> >>
> >> Right. But my point was something like ASPM will add extra complexity
> >> to a feature such as what has been described here. My concern is that
> >> I don't want us implementing stuff on a per-driver basis that is not
> >> all that unique to the device. I don't really see the feature that was
> >> described above as being something that will stay specific to this one
> >> device for very long, especially if it provides added value. Basically
> >> all it is doing is allowing exposing PCIe congestion management to
> >> upper levels in the network stack. I don't even necessarily see it as
> >> being networking specific as I would imagine there might be other
> >> types of devices that could make use of knowing how many transactions
> >> and such they could process at the same time.
> >
> > It sounds to me like you need a library that can be used by all the
> > drivers that need this functionality. Unless it's something
> > documented in the PCIe specs so we can rely on a standard way of
> > discovering and configuring things, I don't see how the PCI core can
> > really be involved.
> >
> > Bjorn
>
> I am kind of thinking that a common library would be a preferred way
> to go, or at least a common interface to share between the drivers. It
> wasn't my intention to imply that the PCI core needed to get involved.
> I was including the linux-pci list as more of a way of checking to get
> the broader audience's input since we were just discussing this on
> netdev.
>
> My main concern is that those of us on netdev have historically we
> have been dealing with features such as SR-IOV as a networking thing,
> when really it has been a combination of a PCI feature and some
> network switching. I might have ratholed this a bit, as I kind of see
> this topic as something similar.
OK, thanks. Sounds like we have similar perspectives and I appreciate
being looped in!
Bjorn
^ permalink raw reply
* Re: unregister_netdevice: waiting for DEV to become free
From: Tetsuo Handa @ 2018-07-31 11:16 UTC (permalink / raw)
To: Steffen Klassert, Herbert Xu, David S. Miller
Cc: syzbot, ddstreet, dvyukov, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <50d24879-7f38-f8c5-982f-b3fc5d3a9cc6@I-love.SAKURA.ne.jp>
Steffen and Herbert,
Do you have any question? I think I provided enough information for debugging.
This problem occurs because two dev_put() calls are missing (compared with not
calling setsockopt(SOL_IPV6, IPV6_XFRM_POLICY)) because dst_release() is not
called via fib6_info_destroy_rcu() when we called xfrm_compile_policy() from
xfrm_user_policy() from setsockopt(SOL_IPV6, IPV6_XFRM_POLICY).
[ 39.981210] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Not tainted 4.18.0-rc6+ #457
[ 39.982879] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
[ 39.985689] Call Trace:
[ 39.986269] <IRQ>
[ 39.986792] dump_stack+0x99/0xdc
[ 39.987601] dst_destroy_hook+0x29/0x2b
[ 39.988517] dst_release+0x28/0x70
[ 39.989481] fib6_info_destroy_rcu+0x8e/0x100
[ 39.990409] ? fib6_walk_continue+0x1c0/0x1c0
[ 39.991355] rcu_process_callbacks+0x2cb/0x870
[ 39.992376] ? rcu_process_callbacks+0x266/0x870
[ 39.993352] __do_softirq+0xcf/0x49b
[ 39.994119] irq_exit+0xc2/0xd0
[ 39.994819] smp_apic_timer_interrupt+0xa4/0x2d0
[ 39.995918] apic_timer_interrupt+0xf/0x20
[ 39.996883] </IRQ>
On 2018/07/27 22:00, Tetsuo Handa wrote:
> Hello.
>
> Since this bug is top crasher (124264 times in 98 days is almost "every minute").
> I made a simplified C reproducer based on the C reproducer provided by syzbot.
> It seems that setsockopt(SOL_IPV6, IPV6_XFRM_POLICY) is involved to this trouble.
>
> ----------------------------------------
> #define _GNU_SOURCE
> #include <sched.h>
> #include <stdlib.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> #include <arpa/inet.h>
>
> /*
> ip6tnl0: flags=128<NOARP> mtu 1452
> unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC)
> RX packets 0 bytes 0 (0.0 B)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 0 bytes 0 (0.0 B)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
> */
> #define IP_DEVNAME "ip6tnl0"
>
> int main(int argc, char *argv[])
> {
> struct sockaddr_in6 addr = { };
> int fd;
> if (unshare(CLONE_NEWNET))
> return 1;
> fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP);
> if (system("ip link set dev " IP_DEVNAME " up"))
> return 2;
> setsockopt(fd, SOL_IPV6, IPV6_XFRM_POLICY, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\254\24\24\252\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0+\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\7\0\0\0\r5M&", 0xe8);
> addr.sin6_family = AF_INET6;
> inet_pton(AF_INET6, "fe80::bb", &addr.sin6_addr);
> addr.sin6_scope_id = 9;
> connect(fd, (struct sockaddr *) &addr, sizeof(addr));
> return 0;
> }
> ----------------------------------------
>
^ permalink raw reply
* Get your Mobile App Development started
From: Vivek Shah @ 2018-07-31 9:36 UTC (permalink / raw)
To: netdev
Hello,
Are you in search of a suitable app development agency to nurture and
transform your creative app idea into reality?
Well, your search ends here.
We are based in India. We are in the mobile app development domain for last
seven years and with
a team of 120+ web and mobile app development professionals, we have served
the global clientele.
Talking about the mobile apps, we have built over 350 mobile apps ranging
from a simple business
app to complex enterprise app to date.
Our expertise in iOS, Android, Ionic, and PhoneGap-based platforms and
various libraries can help
you reach a huge smartphone-using audience with the following services:
• Mobile App Consulting
• Mobile App UI/UX Designing
• Mobile App Development
• Mobile App Maintenance & Support
• Website and eCommerce portal Development
We render our enterprise-grade app development services across different
industry sectors including
retail, games and entertainment, lifestyle, social media, healthcare and
hospitality, BFSI, eCommerce
(m-commerce), food and beverages, and the like.
We will gladly share the references of our work on your demand.
Here is how you can start expanding your business online:
1. Respond to this email
2. We will provide an Action Plan and Quote
3. Get your Mobile App Development started
That's it for now! Thanks for your time.
Awaiting your reply,
Regards,
Vivek Shah
^ permalink raw reply
* Re: KASAN: use-after-free Read in rtnetlink_put_metrics
From: Sabrina Dubroca @ 2018-07-31 13:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: syzbot, christian.brauner, davem, dsahern, fw, jbenc, ktkhai,
linux-kernel, lucien.xin, netdev, syzkaller-bugs
In-Reply-To: <c8ffd001-8c67-19b9-7223-34ca8d436db2@gmail.com>
2018-07-31, 05:41:56 -0700, Eric Dumazet wrote:
>
>
> On 07/31/2018 05:31 AM, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 61f4b23769f0 netlink: Don't shift with UB on nlk->ngroups
> > git tree: net
> > console output: https://syzkaller.appspot.com/x/log.txt?x=14a9de58400000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=ffb4428fdc82f93b
> > dashboard link: https://syzkaller.appspot.com/bug?extid=41f9c04b50ef70c66947
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
[...]
> Probably also caused by :
>
>
> commit df18b50448fab1dff093731dfd0e25e77e1afcd1
> Author: Sabrina Dubroca <sd@queasysnail.net>
> Date: Mon Jul 30 16:23:10 2018 +0200
>
> net/ipv6: fix metrics leak
Yeah, I'm looking into both those reports :/
--
Sabrina
^ permalink raw reply
* [patch net-next 1/2] net: sched: change name of zombie chain to "held_by_acts_only"
From: Jiri Pirko @ 2018-07-31 12:07 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, jakub.kicinski, mlxsw
In-Reply-To: <20180731120745.1230-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@mellanox.com>
As mentioned by Cong and Jakub during the review process, it is a bit
odd to sometimes (act flow) create a new chain which would be
immediately a "zombie". So just rename it to "held_by_acts_only".
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Suggested-by: Cong Wang <xiyou.wangcong@gmail.com>
Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
net/sched/cls_api.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index e20aad1987b8..2f78341f2888 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -272,11 +272,10 @@ static void tcf_chain_release_by_act(struct tcf_chain *chain)
--chain->action_refcnt;
}
-static bool tcf_chain_is_zombie(struct tcf_chain *chain)
+static bool tcf_chain_held_by_acts_only(struct tcf_chain *chain)
{
/* In case all the references are action references, this
- * chain is a zombie and should not be listed in the chain
- * dump list.
+ * chain should not be shown to the user.
*/
return chain->refcnt == chain->action_refcnt;
}
@@ -1838,10 +1837,9 @@ static int tc_ctl_chain(struct sk_buff *skb, struct nlmsghdr *n,
chain = tcf_chain_lookup(block, chain_index);
if (n->nlmsg_type == RTM_NEWCHAIN) {
if (chain) {
- if (tcf_chain_is_zombie(chain)) {
+ if (tcf_chain_held_by_acts_only(chain)) {
/* The chain exists only because there is
- * some action referencing it, meaning it
- * is a zombie.
+ * some action referencing it.
*/
tcf_chain_hold(chain);
} else {
@@ -1860,7 +1858,7 @@ static int tc_ctl_chain(struct sk_buff *skb, struct nlmsghdr *n,
}
}
} else {
- if (!chain || tcf_chain_is_zombie(chain)) {
+ if (!chain || tcf_chain_held_by_acts_only(chain)) {
NL_SET_ERR_MSG(extack, "Cannot find specified filter chain");
return -EINVAL;
}
@@ -1988,7 +1986,7 @@ static int tc_dump_chain(struct sk_buff *skb, struct netlink_callback *cb)
index++;
continue;
}
- if (tcf_chain_is_zombie(chain))
+ if (tcf_chain_held_by_acts_only(chain))
continue;
err = tc_chain_fill_node(chain, net, skb, block,
NETLINK_CB(cb->skb).portid,
--
2.14.4
^ permalink raw reply related
* [patch net-next 0/2] net: sched: couple of adjustments/fixes
From: Jiri Pirko @ 2018-07-31 12:07 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, jakub.kicinski, mlxsw
From: Jiri Pirko <jiri@mellanox.com>
Jiri Pirko (2):
net: sched: change name of zombie chain to "held_by_acts_only"
net: sched: fix notifications for action-held chains
net/sched/cls_api.c | 84 ++++++++++++++++++++++++++++++-----------------------
1 file changed, 48 insertions(+), 36 deletions(-)
--
2.14.4
^ permalink raw reply
* [patch net-next 2/2] net: sched: fix notifications for action-held chains
From: Jiri Pirko @ 2018-07-31 12:07 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, jakub.kicinski, mlxsw
In-Reply-To: <20180731120745.1230-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@mellanox.com>
Chains that only have action references serve as placeholders.
Until a non-action reference is created, user should not be aware
of the chain. Also he should not receive any notifications about it.
So send notifications for the new chain only in case the chain gets
the first non-action reference. Symmetrically to that, when
the last non-action reference is dropped, send the notification about
deleted chain.
Reported-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/cls_api.c | 70 ++++++++++++++++++++++++++++++++---------------------
1 file changed, 42 insertions(+), 28 deletions(-)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 2f78341f2888..ac9b4148878d 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -262,16 +262,6 @@ static void tcf_chain_hold(struct tcf_chain *chain)
++chain->refcnt;
}
-static void tcf_chain_hold_by_act(struct tcf_chain *chain)
-{
- ++chain->action_refcnt;
-}
-
-static void tcf_chain_release_by_act(struct tcf_chain *chain)
-{
- --chain->action_refcnt;
-}
-
static bool tcf_chain_held_by_acts_only(struct tcf_chain *chain)
{
/* In case all the references are action references, this
@@ -295,52 +285,76 @@ static struct tcf_chain *tcf_chain_lookup(struct tcf_block *block,
static int tc_chain_notify(struct tcf_chain *chain, struct sk_buff *oskb,
u32 seq, u16 flags, int event, bool unicast);
-struct tcf_chain *tcf_chain_get(struct tcf_block *block, u32 chain_index,
- bool create)
+struct tcf_chain *__tcf_chain_get(struct tcf_block *block, u32 chain_index,
+ bool create, bool by_act)
{
struct tcf_chain *chain = tcf_chain_lookup(block, chain_index);
if (chain) {
tcf_chain_hold(chain);
- return chain;
+ } else {
+ if (!create)
+ return NULL;
+ chain = tcf_chain_create(block, chain_index);
+ if (!chain)
+ return NULL;
}
- if (!create)
- return NULL;
- chain = tcf_chain_create(block, chain_index);
- if (!chain)
- return NULL;
- tc_chain_notify(chain, NULL, 0, NLM_F_CREATE | NLM_F_EXCL,
- RTM_NEWCHAIN, false);
+ if (by_act)
+ ++chain->action_refcnt;
+
+ /* Send notification only in case we got the first
+ * non-action reference. Until then, the chain acts only as
+ * a placeholder for actions pointing to it and user ought
+ * not know about them.
+ */
+ if (chain->refcnt - chain->action_refcnt == 1 && !by_act)
+ tc_chain_notify(chain, NULL, 0, NLM_F_CREATE | NLM_F_EXCL,
+ RTM_NEWCHAIN, false);
+
return chain;
}
+
+struct tcf_chain *tcf_chain_get(struct tcf_block *block, u32 chain_index,
+ bool create)
+{
+ return __tcf_chain_get(block, chain_index, create, false);
+}
EXPORT_SYMBOL(tcf_chain_get);
struct tcf_chain *tcf_chain_get_by_act(struct tcf_block *block, u32 chain_index)
{
- struct tcf_chain *chain = tcf_chain_get(block, chain_index, true);
-
- tcf_chain_hold_by_act(chain);
- return chain;
+ return __tcf_chain_get(block, chain_index, true, true);
}
EXPORT_SYMBOL(tcf_chain_get_by_act);
static void tc_chain_tmplt_del(struct tcf_chain *chain);
-void tcf_chain_put(struct tcf_chain *chain)
+void __tcf_chain_put(struct tcf_chain *chain, bool by_act)
{
- if (--chain->refcnt == 0) {
+ if (by_act)
+ chain->action_refcnt--;
+ chain->refcnt--;
+
+ /* The last dropped non-action reference will trigger notification. */
+ if (chain->refcnt - chain->action_refcnt == 0 && !by_act)
tc_chain_notify(chain, NULL, 0, 0, RTM_DELCHAIN, false);
+
+ if (chain->refcnt == 0) {
tc_chain_tmplt_del(chain);
tcf_chain_destroy(chain);
}
}
+
+void tcf_chain_put(struct tcf_chain *chain)
+{
+ __tcf_chain_put(chain, false);
+}
EXPORT_SYMBOL(tcf_chain_put);
void tcf_chain_put_by_act(struct tcf_chain *chain)
{
- tcf_chain_release_by_act(chain);
- tcf_chain_put(chain);
+ __tcf_chain_put(chain, true);
}
EXPORT_SYMBOL(tcf_chain_put_by_act);
--
2.14.4
^ permalink raw reply related
* [PATCH] mac80211_hwsim: Fix possible Spectre-v1 for hwsim_world_regdom_custom
From: Jinbum Park @ 2018-07-31 14:10 UTC (permalink / raw)
To: johannes, kvalo, davem
Cc: linux-wireless, netdev, linux-kernel, kernel-hardening
User controls @idx which to be used as index of hwsim_world_regdom_custom.
So, It can be exploited via Spectre-like attack. (speculative execution)
This kind of attack leaks address of hwsim_world_regdom_custom,
It leads an attacker to bypass security mechanism such as KASLR.
So sanitize @idx before using it to prevent attack.
I leveraged strategy [1] to find and exploit this gadget.
[1] https://github.com/jinb-park/linux-exploit/
tree/master/exploit-remaining-spectre-gadget/
Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
---
drivers/net/wireless/mac80211_hwsim.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 998dfac..b41fdc3 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -34,6 +34,7 @@
#include <net/net_namespace.h>
#include <net/netns/generic.h>
#include <linux/rhashtable.h>
+#include <linux/nospec.h>
#include "mac80211_hwsim.h"
#define WARN_QUEUE 100
@@ -3350,6 +3351,9 @@ static int hwsim_new_radio_nl(struct sk_buff *msg, struct genl_info *info)
kfree(hwname);
return -EINVAL;
}
+
+ idx = array_index_nospec(idx,
+ ARRAY_SIZE(hwsim_world_regdom_custom));
param.regd = hwsim_world_regdom_custom[idx];
}
--
1.9.1
^ permalink raw reply related
* [PATCH net-next] qed: Make some functions static
From: YueHaibing @ 2018-07-31 14:12 UTC (permalink / raw)
To: davem, Ariel.Elior, everest-linux-l2; +Cc: linux-kernel, netdev, YueHaibing
Fixes the following sparse warning:
drivers/net/ethernet/qlogic/qed/qed_cxt.c:1534:6: warning: symbol 'qed_cm_init_pf' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_dev.c:233:4: warning: symbol 'qed_init_qm_get_num_tcs' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_dev.c:238:5: warning: symbol 'qed_init_qm_get_num_vfs' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_dev.c:246:5: warning: symbol 'qed_init_qm_get_num_pf_rls' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_dev.c:264:5: warning: symbol 'qed_init_qm_get_num_vports' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_dev.c:276:5: warning: symbol 'qed_init_qm_get_num_pqs' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_mcp.c:573:5: warning: symbol 'qed_mcp_nvm_wr_cmd' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_mcp.c:3012:1: warning: symbol '__qed_mcp_resc_lock' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_dcbx.c:870:6: warning: symbol 'qed_dcbx_aen' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_debug.c:7841:5: warning: symbol 'qed_dbg_nvm_image_length' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_debug.c:7857:5: warning: symbol 'qed_dbg_nvm_image' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_sriov.c:675:6: warning: symbol '_qed_iov_pf_sanity_check' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_sriov.c:690:6: warning: symbol 'qed_iov_pf_sanity_check' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_sriov.c:3982:6: warning: symbol 'qed_iov_pf_get_pending_events' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_vf.c:172:5: warning: symbol '_qed_vf_pf_release' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_rdma.c:137:5: warning: symbol 'qed_rdma_get_sb_id' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_rdma.c:709:5: warning: symbol 'qed_rdma_stop' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_ll2.c:161:6: warning: symbol 'qed_ll2b_complete_rx_packet' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_roce.c:160:6: warning: symbol 'qed_roce_free_cid_pair' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:380:12: warning: symbol 'iwarp_state_names' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:946:1: warning: symbol 'qed_iwarp_parse_private_data' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:971:1: warning: symbol 'qed_iwarp_mpa_reply_arrived' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:2504:1: warning: symbol 'qed_iwarp_ll2_slowpath' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:2806:6: warning: symbol 'qed_iwarp_qp_in_error' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:2827:6: warning: symbol 'qed_iwarp_exception_received' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:2958:1: warning: symbol 'qed_iwarp_connect_complete' was not declared. Should it be static?
drivers/net/ethernet/qlogic/qed/qed_iscsi.c:876:6: warning: symbol 'qed_iscsi_free_connection' was not declared. Should it be static?
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/qlogic/qed/qed_cxt.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_debug.c | 9 +++++----
drivers/net/ethernet/qlogic/qed/qed_dev.c | 10 +++++-----
drivers/net/ethernet/qlogic/qed/qed_iscsi.c | 4 ++--
drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 20 +++++++++++---------
drivers/net/ethernet/qlogic/qed/qed_ll2.c | 3 ++-
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 15 ++++++++-------
drivers/net/ethernet/qlogic/qed/qed_rdma.c | 4 ++--
drivers/net/ethernet/qlogic/qed/qed_roce.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 8 ++++----
drivers/net/ethernet/qlogic/qed/qed_vf.c | 2 +-
12 files changed, 43 insertions(+), 38 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_cxt.c b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
index b5b5ff7..f1977aa 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
@@ -1531,7 +1531,7 @@ void qed_qm_init_pf(struct qed_hwfn *p_hwfn,
}
/* CM PF */
-void qed_cm_init_pf(struct qed_hwfn *p_hwfn)
+static void qed_cm_init_pf(struct qed_hwfn *p_hwfn)
{
/* XCM pure-LB queue */
STORE_RT_REG(p_hwfn, XCM_REG_CON_PHY_Q3_RT_OFFSET,
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index 12b4c2a..d02e774 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -867,7 +867,7 @@ static int qed_dcbx_read_mib(struct qed_hwfn *p_hwfn,
return rc;
}
-void qed_dcbx_aen(struct qed_hwfn *hwfn, u32 mib_type)
+static void qed_dcbx_aen(struct qed_hwfn *hwfn, u32 mib_type)
{
struct qed_common_cb_ops *op = hwfn->cdev->protocol_ops.common;
void *cookie = hwfn->cdev->ops_cookie;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_debug.c b/drivers/net/ethernet/qlogic/qed/qed_debug.c
index 4340c4c..1aa9fc1 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_debug.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_debug.c
@@ -7838,8 +7838,8 @@ int qed_dbg_igu_fifo_size(struct qed_dev *cdev)
return qed_dbg_feature_size(cdev, DBG_FEATURE_IGU_FIFO);
}
-int qed_dbg_nvm_image_length(struct qed_hwfn *p_hwfn,
- enum qed_nvm_images image_id, u32 *length)
+static int qed_dbg_nvm_image_length(struct qed_hwfn *p_hwfn,
+ enum qed_nvm_images image_id, u32 *length)
{
struct qed_nvm_image_att image_att;
int rc;
@@ -7854,8 +7854,9 @@ int qed_dbg_nvm_image_length(struct qed_hwfn *p_hwfn,
return rc;
}
-int qed_dbg_nvm_image(struct qed_dev *cdev, void *buffer,
- u32 *num_dumped_bytes, enum qed_nvm_images image_id)
+static int qed_dbg_nvm_image(struct qed_dev *cdev, void *buffer,
+ u32 *num_dumped_bytes,
+ enum qed_nvm_images image_id)
{
struct qed_hwfn *p_hwfn =
&cdev->hwfns[cdev->dbg_params.engine_for_debug];
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index 37817b3..6a0b46f 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -230,12 +230,12 @@ static u32 qed_get_pq_flags(struct qed_hwfn *p_hwfn)
}
/* Getters for resource amounts necessary for qm initialization */
-u8 qed_init_qm_get_num_tcs(struct qed_hwfn *p_hwfn)
+static u8 qed_init_qm_get_num_tcs(struct qed_hwfn *p_hwfn)
{
return p_hwfn->hw_info.num_hw_tc;
}
-u16 qed_init_qm_get_num_vfs(struct qed_hwfn *p_hwfn)
+static u16 qed_init_qm_get_num_vfs(struct qed_hwfn *p_hwfn)
{
return IS_QED_SRIOV(p_hwfn->cdev) ?
p_hwfn->cdev->p_iov_info->total_vfs : 0;
@@ -243,7 +243,7 @@ u16 qed_init_qm_get_num_vfs(struct qed_hwfn *p_hwfn)
#define NUM_DEFAULT_RLS 1
-u16 qed_init_qm_get_num_pf_rls(struct qed_hwfn *p_hwfn)
+static u16 qed_init_qm_get_num_pf_rls(struct qed_hwfn *p_hwfn)
{
u16 num_pf_rls, num_vfs = qed_init_qm_get_num_vfs(p_hwfn);
@@ -261,7 +261,7 @@ u16 qed_init_qm_get_num_pf_rls(struct qed_hwfn *p_hwfn)
return num_pf_rls;
}
-u16 qed_init_qm_get_num_vports(struct qed_hwfn *p_hwfn)
+static u16 qed_init_qm_get_num_vports(struct qed_hwfn *p_hwfn)
{
u32 pq_flags = qed_get_pq_flags(p_hwfn);
@@ -273,7 +273,7 @@ u16 qed_init_qm_get_num_vports(struct qed_hwfn *p_hwfn)
}
/* calc amount of PQs according to the requested flags */
-u16 qed_init_qm_get_num_pqs(struct qed_hwfn *p_hwfn)
+static u16 qed_init_qm_get_num_pqs(struct qed_hwfn *p_hwfn)
{
u32 pq_flags = qed_get_pq_flags(p_hwfn);
diff --git a/drivers/net/ethernet/qlogic/qed/qed_iscsi.c b/drivers/net/ethernet/qlogic/qed/qed_iscsi.c
index c0d4a54..1135387 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_iscsi.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_iscsi.c
@@ -873,8 +873,8 @@ static void qed_iscsi_release_connection(struct qed_hwfn *p_hwfn,
spin_unlock_bh(&p_hwfn->p_iscsi_info->lock);
}
-void qed_iscsi_free_connection(struct qed_hwfn *p_hwfn,
- struct qed_iscsi_conn *p_conn)
+static void qed_iscsi_free_connection(struct qed_hwfn *p_hwfn,
+ struct qed_iscsi_conn *p_conn)
{
qed_chain_free(p_hwfn->cdev, &p_conn->xhq);
qed_chain_free(p_hwfn->cdev, &p_conn->uhq);
diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
index 90a2b53..17f3dfa 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
@@ -377,7 +377,7 @@ qed_iwarp2roce_state(enum qed_iwarp_qp_state state)
}
}
-const char *iwarp_state_names[] = {
+const static char *iwarp_state_names[] = {
"IDLE",
"RTS",
"TERMINATE",
@@ -942,7 +942,7 @@ qed_iwarp_return_ep(struct qed_hwfn *p_hwfn, struct qed_iwarp_ep *ep)
spin_unlock_bh(&p_hwfn->p_rdma_info->iwarp.iw_lock);
}
-void
+static void
qed_iwarp_parse_private_data(struct qed_hwfn *p_hwfn, struct qed_iwarp_ep *ep)
{
struct mpa_v2_hdr *mpa_v2_params;
@@ -967,7 +967,7 @@ qed_iwarp_parse_private_data(struct qed_hwfn *p_hwfn, struct qed_iwarp_ep *ep)
mpa_data_size;
}
-void
+static void
qed_iwarp_mpa_reply_arrived(struct qed_hwfn *p_hwfn, struct qed_iwarp_ep *ep)
{
struct qed_iwarp_cm_event_params params;
@@ -2500,7 +2500,7 @@ static void qed_iwarp_ll2_rel_tx_pkt(void *cxt, u8 connection_handle,
/* The only slowpath for iwarp ll2 is unalign flush. When this completion
* is received, need to reset the FPDU.
*/
-void
+static void
qed_iwarp_ll2_slowpath(void *cxt,
u8 connection_handle,
u32 opaque_data_0, u32 opaque_data_1)
@@ -2803,8 +2803,9 @@ int qed_iwarp_stop(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
return qed_iwarp_ll2_stop(p_hwfn, p_ptt);
}
-void qed_iwarp_qp_in_error(struct qed_hwfn *p_hwfn,
- struct qed_iwarp_ep *ep, u8 fw_return_code)
+static void qed_iwarp_qp_in_error(struct qed_hwfn *p_hwfn,
+ struct qed_iwarp_ep *ep,
+ u8 fw_return_code)
{
struct qed_iwarp_cm_event_params params;
@@ -2824,8 +2825,9 @@ void qed_iwarp_qp_in_error(struct qed_hwfn *p_hwfn,
ep->event_cb(ep->cb_context, ¶ms);
}
-void qed_iwarp_exception_received(struct qed_hwfn *p_hwfn,
- struct qed_iwarp_ep *ep, int fw_ret_code)
+static void qed_iwarp_exception_received(struct qed_hwfn *p_hwfn,
+ struct qed_iwarp_ep *ep,
+ int fw_ret_code)
{
struct qed_iwarp_cm_event_params params;
bool event_cb = false;
@@ -2954,7 +2956,7 @@ qed_iwarp_tcp_connect_unsuccessful(struct qed_hwfn *p_hwfn,
}
}
-void
+static void
qed_iwarp_connect_complete(struct qed_hwfn *p_hwfn,
struct qed_iwarp_ep *ep, u8 fw_return_code)
{
diff --git a/drivers/net/ethernet/qlogic/qed/qed_ll2.c b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
index 012973d..14ac9ca 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_ll2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
@@ -158,7 +158,8 @@ static void qed_ll2_kill_buffers(struct qed_dev *cdev)
qed_ll2_dealloc_buffer(cdev, buffer);
}
-void qed_ll2b_complete_rx_packet(void *cxt, struct qed_ll2_comp_rx_data *data)
+static void qed_ll2b_complete_rx_packet(void *cxt,
+ struct qed_ll2_comp_rx_data *data)
{
struct qed_hwfn *p_hwfn = cxt;
struct qed_ll2_buffer *buffer = data->cookie;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index 96a67ef..8e4f60e 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -570,12 +570,13 @@ int qed_mcp_cmd(struct qed_hwfn *p_hwfn,
return 0;
}
-int qed_mcp_nvm_wr_cmd(struct qed_hwfn *p_hwfn,
- struct qed_ptt *p_ptt,
- u32 cmd,
- u32 param,
- u32 *o_mcp_resp,
- u32 *o_mcp_param, u32 i_txn_size, u32 *i_buf)
+static int
+qed_mcp_nvm_wr_cmd(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ u32 cmd,
+ u32 param,
+ u32 *o_mcp_resp,
+ u32 *o_mcp_param, u32 i_txn_size, u32 *i_buf)
{
struct qed_mcp_mb_params mb_params;
int rc;
@@ -3008,7 +3009,7 @@ static int qed_mcp_resource_cmd(struct qed_hwfn *p_hwfn,
return rc;
}
-int
+static int
__qed_mcp_resc_lock(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt,
struct qed_resc_lock_params *p_params)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_rdma.c b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
index 101d677..be941cf 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_rdma.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
@@ -134,7 +134,7 @@ static bool qed_bmap_is_empty(struct qed_bmap *bmap)
return bmap->max_count == find_first_bit(bmap->bitmap, bmap->max_count);
}
-u32 qed_rdma_get_sb_id(void *p_hwfn, u32 rel_sb_id)
+static u32 qed_rdma_get_sb_id(void *p_hwfn, u32 rel_sb_id)
{
/* First sb id for RoCE is after all the l2 sb */
return FEAT_NUM((struct qed_hwfn *)p_hwfn, QED_PF_L2_QUE) + rel_sb_id;
@@ -706,7 +706,7 @@ static int qed_rdma_setup(struct qed_hwfn *p_hwfn,
return qed_rdma_start_fw(p_hwfn, params, p_ptt);
}
-int qed_rdma_stop(void *rdma_cxt)
+static int qed_rdma_stop(void *rdma_cxt)
{
struct qed_hwfn *p_hwfn = (struct qed_hwfn *)rdma_cxt;
struct rdma_close_func_ramrod_data *p_ramrod;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_roce.c b/drivers/net/ethernet/qlogic/qed/qed_roce.c
index b5ce158..ada4c18 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_roce.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_roce.c
@@ -157,7 +157,7 @@ static enum roce_flavor qed_roce_mode_to_flavor(enum roce_mode roce_mode)
return flavor;
}
-void qed_roce_free_cid_pair(struct qed_hwfn *p_hwfn, u16 cid)
+static void qed_roce_free_cid_pair(struct qed_hwfn *p_hwfn, u16 cid)
{
spin_lock_bh(&p_hwfn->p_rdma_info->lock);
qed_bmap_release_id(p_hwfn, &p_hwfn->p_rdma_info->cid_map, cid);
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index 26e918d..9b08a9d 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -672,8 +672,8 @@ int qed_iov_hw_info(struct qed_hwfn *p_hwfn)
return 0;
}
-bool _qed_iov_pf_sanity_check(struct qed_hwfn *p_hwfn,
- int vfid, bool b_fail_malicious)
+static bool _qed_iov_pf_sanity_check(struct qed_hwfn *p_hwfn,
+ int vfid, bool b_fail_malicious)
{
/* Check PF supports sriov */
if (IS_VF(p_hwfn->cdev) || !IS_QED_SRIOV(p_hwfn->cdev) ||
@@ -687,7 +687,7 @@ bool _qed_iov_pf_sanity_check(struct qed_hwfn *p_hwfn,
return true;
}
-bool qed_iov_pf_sanity_check(struct qed_hwfn *p_hwfn, int vfid)
+static bool qed_iov_pf_sanity_check(struct qed_hwfn *p_hwfn, int vfid)
{
return _qed_iov_pf_sanity_check(p_hwfn, vfid, true);
}
@@ -3979,7 +3979,7 @@ static void qed_iov_process_mbx_req(struct qed_hwfn *p_hwfn,
}
}
-void qed_iov_pf_get_pending_events(struct qed_hwfn *p_hwfn, u64 *events)
+static void qed_iov_pf_get_pending_events(struct qed_hwfn *p_hwfn, u64 *events)
{
int i;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.c b/drivers/net/ethernet/qlogic/qed/qed_vf.c
index be6ddde..3d42696 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.c
@@ -169,7 +169,7 @@ static void qed_vf_pf_add_qid(struct qed_hwfn *p_hwfn,
p_qid_tlv->qid = p_cid->qid_usage_idx;
}
-int _qed_vf_pf_release(struct qed_hwfn *p_hwfn, bool b_final)
+static int _qed_vf_pf_release(struct qed_hwfn *p_hwfn, bool b_final)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
struct pfvf_def_resp_tlv *resp;
--
2.7.0
^ permalink raw reply related
* Re: [PATCH net-next] virtio_net: force_napi_tx module param.
From: Michael S. Tsirkin @ 2018-07-31 12:34 UTC (permalink / raw)
To: Willem de Bruijn
Cc: David Miller, caleb.raitto, Jason Wang, Network Development,
Caleb Raitto
In-Reply-To: <CAF=yD-+XnL=TowYwdaww7hBkPQek4_cDMSiqo02UaJhKy5PrTA@mail.gmail.com>
On Sun, Jul 29, 2018 at 05:32:56PM -0400, Willem de Bruijn wrote:
> On Sun, Jul 29, 2018 at 12:01 PM David Miller <davem@davemloft.net> wrote:
> >
> > From: Caleb Raitto <caleb.raitto@gmail.com>
> > Date: Mon, 23 Jul 2018 16:11:19 -0700
> >
> > > From: Caleb Raitto <caraitto@google.com>
> > >
> > > The driver disables tx napi if it's not certain that completions will
> > > be processed affine with tx service.
> > >
> > > Its heuristic doesn't account for some scenarios where it is, such as
> > > when the queue pair count matches the core but not hyperthread count.
> > >
> > > Allow userspace to override the heuristic. This is an alternative
> > > solution to that in the linked patch. That added more logic in the
> > > kernel for these cases, but the agreement was that this was better left
> > > to user control.
> > >
> > > Do not expand the existing napi_tx variable to a ternary value,
> > > because doing so can break user applications that expect
> > > boolean ('Y'/'N') instead of integer output. Add a new param instead.
> > >
> > > Link: https://patchwork.ozlabs.org/patch/725249/
> > > Acked-by: Willem de Bruijn <willemb@google.com>
> > > Acked-by: Jon Olson <jonolson@google.com>
> > > Signed-off-by: Caleb Raitto <caraitto@google.com>
> >
> > So I looked into the history surrounding these issues.
> >
> > First of all, it's always ends up turning out crummy when drivers start
> > to set affinities themselves. The worst possible case is to do it
> > _conditionally_, and that is exactly what virtio_net is doing.
> >
> > From the user's perspective, this provides a really bad experience.
> >
> > So if I have a 32-queue device and there are 32 cpus, you'll do all
> > the affinity settings, stopping Irqbalanced from doing anything
> > right?
> >
> > So if I add one more cpu, you'll say "oops, no idea what to do in
> > this situation" and not touch the affinities at all?
> >
> > That makes no sense at all.
> >
> > If the driver is going to set affinities at all, OWN that decision
> > and set it all the time to something reasonable.
> >
> > Or accept that you shouldn't be touching this stuff in the first place
> > and leave the affinities alone.
> >
> > Right now we're kinda in a situation where the driver has been setting
> > affinities in the ncpus==nqueues cases for some time, so we can't stop
> > doing it.
> >
> > Which means we have to set them in all cases to make the user
> > experience sane again.
> >
> > I looked at the linked to patch again:
> >
> > https://patchwork.ozlabs.org/patch/725249/
> >
> > And I think the strategy should be made more generic, to get rid of
> > the hyperthreading assumptions. I also agree that the "assign
> > to first N cpus" logic doesn't make much sense either.
> >
> > Just distribute across the available cpus evenly, and be done with it.
>
> Sounds good to me.
So e.g. we could set an affinity hint to a group of CPUs that
might transmit to this queue.
> > If you have 64 cpus and 32 queues, this assigns queues to every other
> > cpu.
>
> Striping half the number of queues as cores on a hyperthreaded system
> with two logical cores per physical core will allocate all queues on
> only half the physical cores.
>
> But it is probably not safe to make any assumptions on virtual to
> physical core mapping, anyway, which makes the simplest strategy is
> preferable.
^ permalink raw reply
* Greetings From Mrs.Elodie Antoine,
From: Mrs.elodie antoine @ 2018-07-31 12:37 UTC (permalink / raw)
Greetings From Mrs.Elodie Antoine,
May be this letter will definitely come to you as a huge surprise, but
I implore you to take the time to go through it carefully as the
decision you make will go off a long way to determine my future and
continued existence. I am Mrs.Elodie Antoine aging widow of 59 years
old suffering from long time illness.
I have some funds I inherited from my late husband Dr. jean baptiste
antoine,The sum of (US$4.5 Million Dollars) please i want you to
withdraw this fund and use it for Charity works. I found your email
address from the internet after honest prayers to the LORD to bring me
a good person that can handle this project and i decided to contact
you, if you may be willing and interested to handle these trust funds
in good faith before anything happens to me,
Please kindly respond for further details.
Thanks and God bless you,
Mrs.Elodie Antoine
^ permalink raw reply
* [PATCH] net/mlx5e: Fix uninitialized variable
From: Gustavo A. R. Silva @ 2018-07-31 14:21 UTC (permalink / raw)
To: Tariq Toukan, Saeed Mahameed, Leon Romanovsky, David S. Miller
Cc: netdev, linux-rdma, linux-kernel, Gustavo A. R. Silva
There is a potential execution path in which variable *err* is returned
without being properly initialized previously.
Fix this by initializing variable *err* to 0.
Addresses-Coverity-ID: 1472116 ("Uninitialized scalar variable")
Fixes: 0ec13877ce95 ("net/mlx5e: Gather all XDP pre-requisite checks in a single function")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index fde3502..de2827a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -4215,7 +4215,7 @@ static int mlx5e_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
struct mlx5e_priv *priv = netdev_priv(netdev);
struct bpf_prog *old_prog;
bool reset, was_opened;
- int err;
+ int err = 0;
int i;
mutex_lock(&priv->state_lock);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v6 bpf-next 4/9] veth: Handle xdp_frames in xdp napi ring
From: Jesper Dangaard Brouer @ 2018-07-31 12:46 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Alexei Starovoitov, Daniel Borkmann, netdev, Jakub Kicinski,
John Fastabend, Karlsson, Magnus, Björn Töpel, brouer
In-Reply-To: <a63fbf50-aad2-55ca-3f17-0ef72288df54@lab.ntt.co.jp>
On Tue, 31 Jul 2018 19:40:08 +0900
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
> On 2018/07/31 19:26, Jesper Dangaard Brouer wrote:
> >
> > Context needed from: [PATCH v6 bpf-next 2/9] veth: Add driver XDP
> >
> > On Mon, 30 Jul 2018 19:43:44 +0900
> > Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
> >
> >> +static struct sk_buff *veth_build_skb(void *head, int headroom, int len,
> >> + int buflen)
> >> +{
> >> + struct sk_buff *skb;
> >> +
> >> + if (!buflen) {
> >> + buflen = SKB_DATA_ALIGN(headroom + len) +
> >> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> >> + }
> >> + skb = build_skb(head, buflen);
> >> + if (!skb)
> >> + return NULL;
> >> +
> >> + skb_reserve(skb, headroom);
> >> + skb_put(skb, len);
> >> +
> >> + return skb;
> >> +}
> >
> >
> > On Mon, 30 Jul 2018 19:43:46 +0900
> > Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
> >
> >> +static struct sk_buff *veth_xdp_rcv_one(struct veth_priv *priv,
> >> + struct xdp_frame *frame)
> >> +{
> >> + int len = frame->len, delta = 0;
> >> + struct bpf_prog *xdp_prog;
> >> + unsigned int headroom;
> >> + struct sk_buff *skb;
> >> +
> >> + rcu_read_lock();
> >> + xdp_prog = rcu_dereference(priv->xdp_prog);
> >> + if (likely(xdp_prog)) {
> >> + struct xdp_buff xdp;
> >> + u32 act;
> >> +
> >> + xdp.data_hard_start = frame->data - frame->headroom;
> >> + xdp.data = frame->data;
> >> + xdp.data_end = frame->data + frame->len;
> >> + xdp.data_meta = frame->data - frame->metasize;
> >> + xdp.rxq = &priv->xdp_rxq;
> >> +
> >> + act = bpf_prog_run_xdp(xdp_prog, &xdp);
> >> +
> >> + switch (act) {
> >> + case XDP_PASS:
> >> + delta = frame->data - xdp.data;
> >> + len = xdp.data_end - xdp.data;
> >> + break;
> >> + default:
> >> + bpf_warn_invalid_xdp_action(act);
> >> + case XDP_ABORTED:
> >> + trace_xdp_exception(priv->dev, xdp_prog, act);
> >> + case XDP_DROP:
> >> + goto err_xdp;
> >> + }
> >> + }
> >> + rcu_read_unlock();
> >> +
> >> + headroom = frame->data - delta - (void *)frame;
> >> + skb = veth_build_skb(frame, headroom, len, 0);
> >
> > Here you are adding an assumption that struct xdp_frame is always
> > located in-the-top of the packet-data area. I tried hard not to add
> > such a dependency! You can calculate the beginning of the frame from
> > the xdp_frame->data pointer.
> >
> > Why not add such a dependency? Because for AF_XDP zero-copy, we cannot
> > make such an assumption.
> >
> > Currently, when an RX-queue is in AF-XDP-ZC mode (MEM_TYPE_ZERO_COPY)
> > the packet will get dropped when calling convert_to_xdp_frame(), but as
> > the TODO comment indicated in convert_to_xdp_frame() this is not the
> > end-goal.
> >
> > The comment in convert_to_xdp_frame(), indicate we need a full
> > alloc+copy, but that is actually not necessary, if we can just use
> > another memory area for struct xdp_frame, and a pointer to data. Thus,
> > allowing devmap-redir to work-ZC and allow cpumap-redir to do the copy
> > on the remote CPU.
>
> Thanks for pointing this out.
> Seems you are saying xdp_frame area is not reusable. That means we
> reduce usable headroom on every REDIRECT. I wanted to avoid this but
> actually it is impossible, right?
I'm not sure I understand fully... has this something to do, with the
below memset?
When cpumap generate an SKB for the netstack, then we sacrifice/reduce
the SKB headroom available, by in convert_to_xdp_frame() reducing the
headroom by xdp_frame size.
xdp_frame->headroom = headroom - sizeof(*xdp_frame)
In-order to avoid doing such memset of this area. We are actually only
worried about exposing the 'data' pointer, thus we could just clear
that. (See commit 6dfb970d3dbd, this is because Alexei is planing to
move from CAP_SYS_ADMIN to lesser privileged mode CAP_NET_ADMIN)
See commits:
97e19cce05e5 ("bpf: reserve xdp_frame size in xdp headroom")
6dfb970d3dbd ("xdp: avoid leaking info stored in frame data on page reuse")
> >> + if (!skb) {
> >> + xdp_return_frame(frame);
> >> + goto err;
> >> + }
> >> +
> >> + memset(frame, 0, sizeof(*frame));
This memset can become a performance issue later, if we change the size
of xdp_frame. (e.g I'm considering to extend this with the DMA addr,
but I'm not sure about that scheme yet).
Currently sizeof(xdp_frame) == 32 bytes, and a memset of 32 bytes is
fast, due to compiler reasons. Above 32 bytes are more expensive,
because the compiler translates this into a "rep stos" operation, which
is slower, as it needs to save some registers (to allow it to be
interrupted). See [1] for experiments.
[1] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/lib/time_bench_memset.c
> >> + skb->protocol = eth_type_trans(skb, priv->dev);
> >> +err:
> >> + return skb;
> >> +err_xdp:
> >> + rcu_read_unlock();
> >> + xdp_return_frame(frame);
> >> +
> >> + return NULL;
> >> +}
> >
> >
>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: update real_num_rx_queues even when !CONFIG_SYSFS
From: Jesper Dangaard Brouer @ 2018-07-31 13:02 UTC (permalink / raw)
To: Jakub Kicinski
Cc: brouer, davem, alexei.starovoitov, daniel, netdev, oss-drivers,
bjorn.topel
In-Reply-To: <20180731034353.3774-2-jakub.kicinski@netronome.com>
On Mon, 30 Jul 2018 20:43:51 -0700
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> We used to depend on real_num_rx_queues as a upper bound for sanity
> checks. For AF_XDP socket validation it's useful if the check behaves
> the same regardless of CONFIG_SYSFS setting.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
> include/linux/netdevice.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 9c917467a2c7..3bf7e93c9e96 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -3431,8 +3431,9 @@ int netif_set_real_num_tx_queues(struct net_device *dev, unsigned int txq);
> int netif_set_real_num_rx_queues(struct net_device *dev, unsigned int rxq);
> #else
> static inline int netif_set_real_num_rx_queues(struct net_device *dev,
> - unsigned int rxq)
> + unsigned int rxqs)
> {
> + dev->real_num_rx_queues = rxqs;
> return 0;
> }
> #endif
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH] net/mlx5e: Fix uninitialized variable
From: Tariq Toukan @ 2018-07-31 14:50 UTC (permalink / raw)
To: Gustavo A. R. Silva, Tariq Toukan, Saeed Mahameed,
Leon Romanovsky, David S. Miller
Cc: netdev, linux-rdma, linux-kernel
In-Reply-To: <20180731142157.GA24066@embeddedor.com>
On 31/07/2018 5:21 PM, Gustavo A. R. Silva wrote:
> There is a potential execution path in which variable *err* is returned
> without being properly initialized previously.
>
> Fix this by initializing variable *err* to 0.
>
> Addresses-Coverity-ID: 1472116 ("Uninitialized scalar variable")
> Fixes: 0ec13877ce95 ("net/mlx5e: Gather all XDP pre-requisite checks in a single function")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index fde3502..de2827a 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -4215,7 +4215,7 @@ static int mlx5e_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
> struct mlx5e_priv *priv = netdev_priv(netdev);
> struct bpf_prog *old_prog;
> bool reset, was_opened;
> - int err;
> + int err = 0;
> int i;
>
> mutex_lock(&priv->state_lock);
>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Thanks.
^ permalink raw reply
* [PATCH net] bonding: avoid lockdep confusion in bond_get_stats()
From: Eric Dumazet @ 2018-07-31 13:25 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Eric Dumazet, Jay Vosburgh,
Veaceslav Falico, Andy Gospodarek
syzbot found that the following sequence produces a LOCKDEP splat [1]
ip link add bond10 type bond
ip link add bond11 type bond
ip link set bond11 master bond10
To fix this, we can use the already provided nest_level.
This patch also provides correct nesting for dev->addr_list_lock
[1]
WARNING: possible recursive locking detected
4.18.0-rc6+ #167 Not tainted
--------------------------------------------
syz-executor751/4439 is trying to acquire lock:
(____ptrval____) (&(&bond->stats_lock)->rlock){+.+.}, at: spin_lock include/linux/spinlock.h:310 [inline]
(____ptrval____) (&(&bond->stats_lock)->rlock){+.+.}, at: bond_get_stats+0xb4/0x560 drivers/net/bonding/bond_main.c:3426
but task is already holding lock:
(____ptrval____) (&(&bond->stats_lock)->rlock){+.+.}, at: spin_lock include/linux/spinlock.h:310 [inline]
(____ptrval____) (&(&bond->stats_lock)->rlock){+.+.}, at: bond_get_stats+0xb4/0x560 drivers/net/bonding/bond_main.c:3426
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&bond->stats_lock)->rlock);
lock(&(&bond->stats_lock)->rlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by syz-executor751/4439:
#0: (____ptrval____) (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20 net/core/rtnetlink.c:77
#1: (____ptrval____) (&(&bond->stats_lock)->rlock){+.+.}, at: spin_lock include/linux/spinlock.h:310 [inline]
#1: (____ptrval____) (&(&bond->stats_lock)->rlock){+.+.}, at: bond_get_stats+0xb4/0x560 drivers/net/bonding/bond_main.c:3426
#2: (____ptrval____) (rcu_read_lock){....}, at: bond_get_stats+0x0/0x560 include/linux/compiler.h:215
stack backtrace:
CPU: 0 PID: 4439 Comm: syz-executor751 Not tainted 4.18.0-rc6+ #167
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_deadlock_bug kernel/locking/lockdep.c:1765 [inline]
check_deadlock kernel/locking/lockdep.c:1809 [inline]
validate_chain kernel/locking/lockdep.c:2405 [inline]
__lock_acquire.cold.64+0x1fb/0x486 kernel/locking/lockdep.c:3435
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:310 [inline]
bond_get_stats+0xb4/0x560 drivers/net/bonding/bond_main.c:3426
dev_get_stats+0x10f/0x470 net/core/dev.c:8316
bond_get_stats+0x232/0x560 drivers/net/bonding/bond_main.c:3432
dev_get_stats+0x10f/0x470 net/core/dev.c:8316
rtnl_fill_stats+0x4d/0xac0 net/core/rtnetlink.c:1169
rtnl_fill_ifinfo+0x1aa6/0x3fb0 net/core/rtnetlink.c:1611
rtmsg_ifinfo_build_skb+0xc8/0x190 net/core/rtnetlink.c:3268
rtmsg_ifinfo_event.part.30+0x45/0xe0 net/core/rtnetlink.c:3300
rtmsg_ifinfo_event net/core/rtnetlink.c:3297 [inline]
rtnetlink_event+0x144/0x170 net/core/rtnetlink.c:4716
notifier_call_chain+0x180/0x390 kernel/notifier.c:93
__raw_notifier_call_chain kernel/notifier.c:394 [inline]
raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1735
call_netdevice_notifiers net/core/dev.c:1753 [inline]
netdev_features_change net/core/dev.c:1321 [inline]
netdev_change_features+0xb3/0x110 net/core/dev.c:7759
bond_compute_features.isra.47+0x585/0xa50 drivers/net/bonding/bond_main.c:1120
bond_enslave+0x1b25/0x5da0 drivers/net/bonding/bond_main.c:1755
bond_do_ioctl+0x7cb/0xae0 drivers/net/bonding/bond_main.c:3528
dev_ifsioc+0x43c/0xb30 net/core/dev_ioctl.c:327
dev_ioctl+0x1b5/0xcc0 net/core/dev_ioctl.c:493
sock_do_ioctl+0x1d3/0x3e0 net/socket.c:992
sock_ioctl+0x30d/0x680 net/socket.c:1093
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x1de/0x1720 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+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440859
Code: e8 2c af 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffc51a92878 EFLAGS: 00000213 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000440859
RDX: 0000000020000040 RSI: 0000000000008990 RDI: 0000000000000003
RBP: 0000000000000000 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000022d5880 R11: 0000000000000213 R12: 0000000000007390
R13: 0000000000401db0 R14: 0000000000000000 R15: 0000000000000000
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jay Vosburgh <j.vosburgh@gmail.com>
Cc: Veaceslav Falico <vfalico@gmail.com>
Cc: Andy Gospodarek <andy@greyhouse.net>
---
drivers/net/bonding/bond_main.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 63e3844c5becf5e973e10fa2aa533f668ac8e30b..db06d72f3f1c15800646b68c70aa5fda35e7e712 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1717,6 +1717,8 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
goto err_upper_unlink;
}
+ bond->nest_level = dev_get_nest_level(bond_dev) + 1;
+
/* If the mode uses primary, then the following is handled by
* bond_change_active_slave().
*/
@@ -1764,7 +1766,6 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
if (bond_mode_can_use_xmit_hash(bond))
bond_update_slave_arr(bond, NULL);
- bond->nest_level = dev_get_nest_level(bond_dev);
netdev_info(bond_dev, "Enslaving %s as %s interface with %s link\n",
slave_dev->name,
@@ -3415,6 +3416,13 @@ static void bond_fold_stats(struct rtnl_link_stats64 *_res,
}
}
+static int bond_get_nest_level(struct net_device *bond_dev)
+{
+ struct bonding *bond = netdev_priv(bond_dev);
+
+ return bond->nest_level;
+}
+
static void bond_get_stats(struct net_device *bond_dev,
struct rtnl_link_stats64 *stats)
{
@@ -3423,7 +3431,7 @@ static void bond_get_stats(struct net_device *bond_dev,
struct list_head *iter;
struct slave *slave;
- spin_lock(&bond->stats_lock);
+ spin_lock_nested(&bond->stats_lock, bond_get_nest_level(bond_dev));
memcpy(stats, &bond->bond_stats, sizeof(*stats));
rcu_read_lock();
@@ -4227,6 +4235,7 @@ static const struct net_device_ops bond_netdev_ops = {
.ndo_neigh_setup = bond_neigh_setup,
.ndo_vlan_rx_add_vid = bond_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = bond_vlan_rx_kill_vid,
+ .ndo_get_lock_subclass = bond_get_nest_level,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_netpoll_setup = bond_netpoll_setup,
.ndo_netpoll_cleanup = bond_netpoll_cleanup,
@@ -4713,6 +4722,8 @@ static int bond_check_params(struct bond_params *params)
return 0;
}
+static struct lock_class_key bond_netdev_addr_lock_key;
+
/* Called from registration process */
static int bond_init(struct net_device *bond_dev)
{
@@ -4725,6 +4736,7 @@ static int bond_init(struct net_device *bond_dev)
if (!bond->wq)
return -ENOMEM;
+ bond->nest_level = SINGLE_DEPTH_NESTING;
netdev_lockdep_set_classes(bond_dev);
list_add_tail(&bond->bond_list, &bn->dev_list);
--
2.18.0.345.g5c9ce644c3-goog
^ permalink raw reply related
* Re: [PATCH net] bonding: avoid lockdep confusion in bond_get_stats()
From: Eric Dumazet @ 2018-07-31 13:28 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller
Cc: netdev, Eric Dumazet, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek
In-Reply-To: <20180731132522.57029-1-edumazet@google.com>
On 07/31/2018 06:25 AM, Eric Dumazet wrote:
> syzbot found that the following sequence produces a LOCKDEP splat [1]
>
> ip link add bond10 type bond
> ip link add bond11 type bond
> ip link set bond11 master bond10
...
> +static struct lock_class_key bond_netdev_addr_lock_key;
> +
Oops, this part is not needed, I will send a V2
^ permalink raw reply
* [PATCH v2 net] bonding: avoid lockdep confusion in bond_get_stats()
From: Eric Dumazet @ 2018-07-31 13:30 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Eric Dumazet, Jay Vosburgh,
Veaceslav Falico, Andy Gospodarek
syzbot found that the following sequence produces a LOCKDEP splat [1]
ip link add bond10 type bond
ip link add bond11 type bond
ip link set bond11 master bond10
To fix this, we can use the already provided nest_level.
This patch also provides correct nesting for dev->addr_list_lock
[1]
WARNING: possible recursive locking detected
4.18.0-rc6+ #167 Not tainted
--------------------------------------------
syz-executor751/4439 is trying to acquire lock:
(____ptrval____) (&(&bond->stats_lock)->rlock){+.+.}, at: spin_lock include/linux/spinlock.h:310 [inline]
(____ptrval____) (&(&bond->stats_lock)->rlock){+.+.}, at: bond_get_stats+0xb4/0x560 drivers/net/bonding/bond_main.c:3426
but task is already holding lock:
(____ptrval____) (&(&bond->stats_lock)->rlock){+.+.}, at: spin_lock include/linux/spinlock.h:310 [inline]
(____ptrval____) (&(&bond->stats_lock)->rlock){+.+.}, at: bond_get_stats+0xb4/0x560 drivers/net/bonding/bond_main.c:3426
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&bond->stats_lock)->rlock);
lock(&(&bond->stats_lock)->rlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by syz-executor751/4439:
#0: (____ptrval____) (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20 net/core/rtnetlink.c:77
#1: (____ptrval____) (&(&bond->stats_lock)->rlock){+.+.}, at: spin_lock include/linux/spinlock.h:310 [inline]
#1: (____ptrval____) (&(&bond->stats_lock)->rlock){+.+.}, at: bond_get_stats+0xb4/0x560 drivers/net/bonding/bond_main.c:3426
#2: (____ptrval____) (rcu_read_lock){....}, at: bond_get_stats+0x0/0x560 include/linux/compiler.h:215
stack backtrace:
CPU: 0 PID: 4439 Comm: syz-executor751 Not tainted 4.18.0-rc6+ #167
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_deadlock_bug kernel/locking/lockdep.c:1765 [inline]
check_deadlock kernel/locking/lockdep.c:1809 [inline]
validate_chain kernel/locking/lockdep.c:2405 [inline]
__lock_acquire.cold.64+0x1fb/0x486 kernel/locking/lockdep.c:3435
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:310 [inline]
bond_get_stats+0xb4/0x560 drivers/net/bonding/bond_main.c:3426
dev_get_stats+0x10f/0x470 net/core/dev.c:8316
bond_get_stats+0x232/0x560 drivers/net/bonding/bond_main.c:3432
dev_get_stats+0x10f/0x470 net/core/dev.c:8316
rtnl_fill_stats+0x4d/0xac0 net/core/rtnetlink.c:1169
rtnl_fill_ifinfo+0x1aa6/0x3fb0 net/core/rtnetlink.c:1611
rtmsg_ifinfo_build_skb+0xc8/0x190 net/core/rtnetlink.c:3268
rtmsg_ifinfo_event.part.30+0x45/0xe0 net/core/rtnetlink.c:3300
rtmsg_ifinfo_event net/core/rtnetlink.c:3297 [inline]
rtnetlink_event+0x144/0x170 net/core/rtnetlink.c:4716
notifier_call_chain+0x180/0x390 kernel/notifier.c:93
__raw_notifier_call_chain kernel/notifier.c:394 [inline]
raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1735
call_netdevice_notifiers net/core/dev.c:1753 [inline]
netdev_features_change net/core/dev.c:1321 [inline]
netdev_change_features+0xb3/0x110 net/core/dev.c:7759
bond_compute_features.isra.47+0x585/0xa50 drivers/net/bonding/bond_main.c:1120
bond_enslave+0x1b25/0x5da0 drivers/net/bonding/bond_main.c:1755
bond_do_ioctl+0x7cb/0xae0 drivers/net/bonding/bond_main.c:3528
dev_ifsioc+0x43c/0xb30 net/core/dev_ioctl.c:327
dev_ioctl+0x1b5/0xcc0 net/core/dev_ioctl.c:493
sock_do_ioctl+0x1d3/0x3e0 net/socket.c:992
sock_ioctl+0x30d/0x680 net/socket.c:1093
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x1de/0x1720 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+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440859
Code: e8 2c af 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffc51a92878 EFLAGS: 00000213 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000440859
RDX: 0000000020000040 RSI: 0000000000008990 RDI: 0000000000000003
RBP: 0000000000000000 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000022d5880 R11: 0000000000000213 R12: 0000000000007390
R13: 0000000000401db0 R14: 0000000000000000 R15: 0000000000000000
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jay Vosburgh <j.vosburgh@gmail.com>
Cc: Veaceslav Falico <vfalico@gmail.com>
Cc: Andy Gospodarek <andy@greyhouse.net>
---
drivers/net/bonding/bond_main.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 63e3844c5becf5e973e10fa2aa533f668ac8e30b..217b790d22edc2fdd90d4f3c634cb2fa38bc095f 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1717,6 +1717,8 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
goto err_upper_unlink;
}
+ bond->nest_level = dev_get_nest_level(bond_dev) + 1;
+
/* If the mode uses primary, then the following is handled by
* bond_change_active_slave().
*/
@@ -1764,7 +1766,6 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
if (bond_mode_can_use_xmit_hash(bond))
bond_update_slave_arr(bond, NULL);
- bond->nest_level = dev_get_nest_level(bond_dev);
netdev_info(bond_dev, "Enslaving %s as %s interface with %s link\n",
slave_dev->name,
@@ -3415,6 +3416,13 @@ static void bond_fold_stats(struct rtnl_link_stats64 *_res,
}
}
+static int bond_get_nest_level(struct net_device *bond_dev)
+{
+ struct bonding *bond = netdev_priv(bond_dev);
+
+ return bond->nest_level;
+}
+
static void bond_get_stats(struct net_device *bond_dev,
struct rtnl_link_stats64 *stats)
{
@@ -3423,7 +3431,7 @@ static void bond_get_stats(struct net_device *bond_dev,
struct list_head *iter;
struct slave *slave;
- spin_lock(&bond->stats_lock);
+ spin_lock_nested(&bond->stats_lock, bond_get_nest_level(bond_dev));
memcpy(stats, &bond->bond_stats, sizeof(*stats));
rcu_read_lock();
@@ -4227,6 +4235,7 @@ static const struct net_device_ops bond_netdev_ops = {
.ndo_neigh_setup = bond_neigh_setup,
.ndo_vlan_rx_add_vid = bond_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = bond_vlan_rx_kill_vid,
+ .ndo_get_lock_subclass = bond_get_nest_level,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_netpoll_setup = bond_netpoll_setup,
.ndo_netpoll_cleanup = bond_netpoll_cleanup,
@@ -4725,6 +4734,7 @@ static int bond_init(struct net_device *bond_dev)
if (!bond->wq)
return -ENOMEM;
+ bond->nest_level = SINGLE_DEPTH_NESTING;
netdev_lockdep_set_classes(bond_dev);
list_add_tail(&bond->bond_list, &bn->dev_list);
--
2.18.0.345.g5c9ce644c3-goog
^ permalink raw reply related
* Re: KASAN: stack-out-of-bounds Read in bpf_tcp_close
From: John Fastabend @ 2018-07-31 15:25 UTC (permalink / raw)
To: syzbot, ast, daniel, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <0000000000002f5daa05714d739b@google.com>
On 07/18/2018 03:19 PM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 8ae71e76cf1f Merge branch 'bpf-offload-sharing'
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1379a978400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=89129667b46496c3
> dashboard link: https://syzkaller.appspot.com/bug?extid=65a97319fd875ea52b73
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=114f4b2c400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1774932c400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+65a97319fd875ea52b73@syzkaller.appspotmail.com
>
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> IPVS: ftp: loaded support on port[0] = 21
> ==================================================================
> swap_info_get: Bad swap file entry 8007fffc400d72b
> BUG: KASAN: stack-out-of-bounds in __read_once_size include/linux/compiler.h:188 [inline]
> BUG: KASAN: stack-out-of-bounds in smap_psock_sk kernel/bpf/sockmap.c:149 [inline]
> BUG: KASAN: stack-out-of-bounds in bpf_tcp_close+0xf10/0x1050 kernel/bpf/sockmap.c:316
> Read of size 8 at addr ffff8801adcc4428 by task syz-executor115/24313
> BUG: Bad page map in process syz-executor115 pte:1ffff10035cac810 pmd:1ae564067
>
> CPU: 0 PID: 24313 Comm: syz-executor115 Not tainted 4.18.0-rc3+ #58
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
>
> addr:(____ptrval____) vm_flags:00000875 anon_vma: (null) mapping:(____ptrval____) index:0
> Allocated by task 2294230744:
> usercopy: Kernel memory overwrite attempt detected to SLAB object 'task_struct(17:syz0)' (offset 6088, size 2)!
> file:syz-executor115250413 fault:ext4_filemap_fault mmap:ext4_file_mmap readpage:ext4_readpage
> ------------[ cut here ]------------
> Bad or missing usercopy whitelist? Kernel memory overwrite attempt detected to SLAB object 'task_struct(17:syz0)' (offset 4936, size 2)!
> WARNING: CPU: 0 PID: 24313 at mm/usercopy.c:81 usercopy_warn+0xf5/0x120 mm/usercopy.c:76
> CPU: 1 PID: 4479 Comm: syz-executor115 Not tainted 4.18.0-rc3+ #58
> Kernel panic - not syncing: panic_on_warn set ...
>
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> print_bad_pte.cold.116+0x1cd/0x22b mm/memory.c:774
> zap_pte_range mm/memory.c:1380 [inline]
> zap_pmd_range mm/memory.c:1437 [inline]
> zap_pud_range mm/memory.c:1466 [inline]
> zap_p4d_range mm/memory.c:1487 [inline]
> unmap_page_range+0x1cb9/0x2220 mm/memory.c:1508
> unmap_single_vma+0x1a0/0x310 mm/memory.c:1553
> unmap_vmas+0x120/0x1f0 mm/memory.c:1583
> exit_mmap+0x2c2/0x5b0 mm/mmap.c:3105
> __mmput kernel/fork.c:970 [inline]
> mmput+0x265/0x620 kernel/fork.c:991
> exit_mm kernel/exit.c:544 [inline]
> do_exit+0xea9/0x2750 kernel/exit.c:852
> do_group_exit+0x177/0x440 kernel/exit.c:968
> get_signal+0x88e/0x1970 kernel/signal.c:2468
> do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816
> exit_to_usermode_loop+0x2e0/0x370 arch/x86/entry/common.c:162
> prepare_exit_to_usermode+0x342/0x3b0 arch/x86/entry/common.c:197
> retint_user+0x8/0x18
> RIP: 0033:0x4731e0
> Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> RSP: 002b:00007ffd426a9928 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: 0000000000002e7e RCX: 00000000004731e0
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007ffd426a9930
> RBP: 0000000000002e7e R08: 0000000000000001 R09: 0000000000e2a880
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000f7e
> R13: 000000000003ab5f R14: 0000000000000000 R15: 0000000000000000
> CPU: 0 PID: 24313 Comm: syz-executor115 Not tainted 4.18.0-rc3+ #58
> swap_info_get: Bad swap file entry 403fffe200725fc
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
Seems KCM and ULPs are colliding here, sockmap/tls need
some extra checks. I'll have a fix shortly.
Thanks,
John
^ permalink raw reply
* Re: [PATCH net-next 1/7] net: ipv4: Control SKB reprioritization after forwarding
From: Nikolay Aleksandrov @ 2018-07-31 13:50 UTC (permalink / raw)
To: Petr Machata, netdev, linux-doc, linux-kselftest
Cc: davem, corbet, jiri, idosch, kuznet, yoshfuji, shuah, dsahern
In-Reply-To: <56e17ee7750b89ff350735ff7cbaf14c63864586.1533030830.git.petrm@mellanox.com>
On 07/31/2018 12:56 PM, Petr Machata wrote:
> After IPv4 packets are forwarded, the priority of the corresponding SKB
> is updated according to the TOS field of IPv4 header. This overrides any
> prioritization done earlier by e.g. an skbedit action or ingress-qos-map
> defined at a vlan device.
...
> diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
> index 661348f23ea5..e47503b4e4d1 100644
> --- a/include/net/netns/ipv4.h
> +++ b/include/net/netns/ipv4.h
> @@ -98,6 +98,7 @@ struct netns_ipv4 {
> int sysctl_ip_default_ttl;
> int sysctl_ip_no_pmtu_disc;
> int sysctl_ip_fwd_use_pmtu;
> + int sysctl_ip_fwd_update_priority;
> int sysctl_ip_nonlocal_bind;
> /* Shall we try to damage output packets if routing dev changes? */
> int sysctl_ip_dynaddr;
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index f2a0a3bab6b5..d3cfbd89ca3a 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1802,6 +1802,7 @@ static __net_init int inet_init_net(struct net *net)
> * We set them here, in case sysctl is not compiled.
> */
> net->ipv4.sysctl_ip_default_ttl = IPDEFTTL;
> + net->ipv4.sysctl_ip_fwd_update_priority = true;
nit: since this is an int and to keep the code style of inet_init_net()
I'd suggest to use 1 instead
> net->ipv4.sysctl_ip_dynaddr = 0;
> net->ipv4.sysctl_ip_early_demux = 1;
> net->ipv4.sysctl_udp_early_demux = 1;
...
^ permalink raw reply
* Re: [PATCH net-next v5 1/4] net/sched: user-space can't set unknown tcfa_action values
From: Jamal Hadi Salim @ 2018-07-31 13:53 UTC (permalink / raw)
To: Paolo Abeni, netdev
Cc: Cong Wang, Jiri Pirko, Daniel Borkmann, Marcelo Ricardo Leitner,
Eyal Birger, David S. Miller
In-Reply-To: <b36ee3a23d828c304e0bbcb872499600ad9bf162.camel@redhat.com>
On 31/07/18 05:41 AM, Paolo Abeni wrote:
> Before this patch, the kernel exposed the same behaviour for negative
> value of 'bar', while, for positive 'bar' values, the overall behaviour
> was more complex (some classifier always stops with unknown positive
> action value, others go to lower prio).
>
>
> Overall, the kernel behavior should be more well-defined now, but yes,
> there is a change of behavior under some circumstances.
>
> What about instead mapping undefined/unknown actions value to TC_ACT_OK
> (still at initialization time)? >
> this is what is already done by
> tcf_action_exec() for faulty opcodes/graphs and by tcf_ipt() and would
> handle the above example more conistently.
>
I think PIPE maybe more reasonable. You still continue the action graph
even on such a mis-configuration.
But let me see if i can make a convincing arguement for rejecting at
init time:
I would be _very suprised_ if someone is depending on a misconfiguration
such as this in a deployment because they would get different results
than what they are expecting and sooner or later fix it after a lot of
debugging and cursing. Your patch helps them notice it sooner. And a
rejection even much much sooner. With a rejection you dont get to
execute a "fixup" the kernel assumes for you.
BTW, I asked this earlier and Jiri said it was addressed in patch 2.
I just looked again and i may be missing something basic:
Lets say tomorrow in a new kernel we add new TC_ACT_XXX that then gets
exposed to uapi - so user space tc is updated.
You then use the new tc specifying TC_ACT_XXX policy on kernel with your
changes.
If i read correctly because TC_ACT_XXX is out of bounds for current
kernel(which has your changes) you will fix it to be UNSPEC, no?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next 1/7] net: ipv4: Control SKB reprioritization after forwarding
From: Petr Machata @ 2018-07-31 14:01 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: netdev, linux-doc, linux-kselftest, davem, corbet, jiri, idosch,
kuznet, yoshfuji, shuah, dsahern
In-Reply-To: <5746599c-64b1-f283-cb15-b980605cb704@cumulusnetworks.com>
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> writes:
>> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
>> index f2a0a3bab6b5..d3cfbd89ca3a 100644
>> --- a/net/ipv4/af_inet.c
>> +++ b/net/ipv4/af_inet.c
>> @@ -1802,6 +1802,7 @@ static __net_init int inet_init_net(struct net *net)
>> * We set them here, in case sysctl is not compiled.
>> */
>> net->ipv4.sysctl_ip_default_ttl = IPDEFTTL;
>> + net->ipv4.sysctl_ip_fwd_update_priority = true;
>
> nit: since this is an int and to keep the code style of inet_init_net()
> I'd suggest to use 1 instead
OK.
Thanks,
Petr
^ 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