* WARNING: suspicious RCU usage in idtentry_exit
@ 2020-05-26 3:54 syzbot
2020-05-28 13:33 ` Thomas Gleixner
0 siblings, 1 reply; 11+ messages in thread
From: syzbot @ 2020-05-26 3:54 UTC (permalink / raw)
To: bp, hpa, linux-kernel, luto, mingo, syzkaller-bugs, tglx, x86
Hello,
syzbot found the following crash on:
HEAD commit: 7b4cb0a4 Add linux-next specific files for 20200525
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13356016100000
kernel config: https://syzkaller.appspot.com/x/.config?x=47b0740d89299c10
dashboard link: https://syzkaller.appspot.com/bug?extid=3ae5eaae0809ee311e75
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3ae5eaae0809ee311e75@syzkaller.appspotmail.com
=============================
WARNING: suspicious RCU usage
5.7.0-rc7-next-20200525-syzkaller #0 Not tainted
-----------------------------
kernel/rcu/tree.c:715 RCU dynticks_nesting counter underflow/zero!!
other info that might help us debug this:
RCU used illegally from idle CPU!
rcu_scheduler_active = 2, debug_locks = 1
RCU used illegally from extended quiescent state!
no locks held by syz-executor.5/24641.
stack backtrace:
CPU: 1 PID: 24641 Comm: syz-executor.5 Not tainted 5.7.0-rc7-next-20200525-syzkaller #0
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+0x18f/0x20d lib/dump_stack.c:118
rcu_irq_exit_preempt+0x1fa/0x250 kernel/rcu/tree.c:715
idtentry_exit+0x9e/0xc0 arch/x86/entry/common.c:583
exc_general_protection+0x23d/0x520 arch/x86/kernel/traps.c:506
asm_exc_general_protection+0x1e/0x30 arch/x86/include/asm/idtentry.h:353
RIP: 0010:kvm_fastop_exception+0xb68/0xfe8
Code: f2 ff ff ff 48 31 db e9 fb c9 2a f9 b8 f2 ff ff ff 48 31 f6 e9 ff c9 2a f9 31 c0 e9 ec 2c 2b f9 b8 fb ff ff ff e9 13 a9 31 f9 <b9> fb ff ff ff 31 c0 31 d2 e9 33 a9 31 f9 31 db e9 2a 0b 42 f9 31
RSP: 0018:ffffc90004a87a30 EFLAGS: 00010212
RAX: 0000000000040000 RBX: ffff88809cca4080 RCX: 0000000000000122
RDX: 00000000000063ff RSI: ffffc90004a87a98 RDI: 0000000000000122
RBP: 0000000000000122 R08: ffff888058486480 R09: fffffbfff131f481
R10: ffffffff898fa403 R11: fffffbfff131f480 R12: 0000000000000122
R13: 0000000000000078 R14: 0000000000000006 R15: ffffffff88244b5c
paravirt_read_msr_safe arch/x86/include/asm/paravirt.h:178 [inline]
vmx_create_vcpu+0x184/0x2b40 arch/x86/kvm/vmx/vmx.c:6827
kvm_arch_vcpu_create+0x6a8/0xb30 arch/x86/kvm/x86.c:9427
kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3043 [inline]
kvm_vm_ioctl+0x15b7/0x2460 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3603
vfs_ioctl fs/ioctl.c:48 [inline]
ksys_ioctl+0x11a/0x180 fs/ioctl.c:753
__do_sys_ioctl fs/ioctl.c:762 [inline]
__se_sys_ioctl fs/ioctl.c:760 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:353
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ca29
Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2c93b11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004e73c0 RCX: 000000000045ca29
RDX: 0000000000000000 RSI: 000000000000ae41 RDI: 0000000000000004
RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000396 R14: 00000000004c62c6 R15: 00007f2c93b126d4
=============================
WARNING: suspicious RCU usage
5.7.0-rc7-next-20200525-syzkaller #0 Not tainted
-----------------------------
kernel/rcu/tree.c:717 RCU in extended quiescent state!!
other info that might help us debug this:
RCU used illegally from idle CPU!
rcu_scheduler_active = 2, debug_locks = 1
RCU used illegally from extended quiescent state!
no locks held by syz-executor.5/24641.
stack backtrace:
CPU: 1 PID: 24641 Comm: syz-executor.5 Not tainted 5.7.0-rc7-next-20200525-syzkaller #0
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+0x18f/0x20d lib/dump_stack.c:118
idtentry_exit+0x9e/0xc0 arch/x86/entry/common.c:583
exc_general_protection+0x23d/0x520 arch/x86/kernel/traps.c:506
asm_exc_general_protection+0x1e/0x30 arch/x86/include/asm/idtentry.h:353
RIP: 0010:kvm_fastop_exception+0xb68/0xfe8
Code: f2 ff ff ff 48 31 db e9 fb c9 2a f9 b8 f2 ff ff ff 48 31 f6 e9 ff c9 2a f9 31 c0 e9 ec 2c 2b f9 b8 fb ff ff ff e9 13 a9 31 f9 <b9> fb ff ff ff 31 c0 31 d2 e9 33 a9 31 f9 31 db e9 2a 0b 42 f9 31
RSP: 0018:ffffc90004a87a30 EFLAGS: 00010212
RAX: 0000000000040000 RBX: ffff88809cca4080 RCX: 0000000000000122
RDX: 00000000000063ff RSI: ffffc90004a87a98 RDI: 0000000000000122
RBP: 0000000000000122 R08: ffff888058486480 R09: fffffbfff131f481
R10: ffffffff898fa403 R11: fffffbfff131f480 R12: 0000000000000122
R13: 0000000000000078 R14: 0000000000000006 R15: ffffffff88244b5c
paravirt_read_msr_safe arch/x86/include/asm/paravirt.h:178 [inline]
vmx_create_vcpu+0x184/0x2b40 arch/x86/kvm/vmx/vmx.c:6827
kvm_arch_vcpu_create+0x6a8/0xb30 arch/x86/kvm/x86.c:9427
kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3043 [inline]
kvm_vm_ioctl+0x15b7/0x2460 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3603
vfs_ioctl fs/ioctl.c:48 [inline]
ksys_ioctl+0x11a/0x180 fs/ioctl.c:753
__do_sys_ioctl fs/ioctl.c:762 [inline]
__se_sys_ioctl fs/ioctl.c:760 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:353
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ca29
Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2c93b11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004e73c0 RCX: 000000000045ca29
RDX: 0000000000000000 RSI: 000000000000ae41 RDI: 0000000000000004
RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000396 R14: 00000000004c62c6 R15: 00007f2c93b126d4
=============================
WARNING: suspicious RCU usage
5.7.0-rc7-next-20200525-syzkaller #0 Not tainted
-----------------------------
include/trace/events/rcu.h:27 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
RCU used illegally from idle CPU!
rcu_scheduler_active = 2, debug_locks = 1
RCU used illegally from extended quiescent state!
no locks held by syz-executor.5/24641.
stack backtrace:
CPU: 1 PID: 24641 Comm: syz-executor.5 Not tainted 5.7.0-rc7-next-20200525-syzkaller #0
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+0x18f/0x20d lib/dump_stack.c:118
trace_rcu_utilization include/trace/events/rcu.h:27 [inline]
trace_rcu_utilization include/trace/events/rcu.h:27 [inline]
rcu_note_context_switch+0x113d/0x1b20 kernel/rcu/tree_plugin.h:293
__schedule+0x22b/0x1f70 kernel/sched/core.c:4058
preempt_schedule_irq+0xb0/0x150 kernel/sched/core.c:4380
idtentry_exit+0xb9/0xc0 arch/x86/entry/common.c:585
exc_general_protection+0x23d/0x520 arch/x86/kernel/traps.c:506
asm_exc_general_protection+0x1e/0x30 arch/x86/include/asm/idtentry.h:353
RIP: 0010:kvm_fastop_exception+0xb68/0xfe8
Code: f2 ff ff ff 48 31 db e9 fb c9 2a f9 b8 f2 ff ff ff 48 31 f6 e9 ff c9 2a f9 31 c0 e9 ec 2c 2b f9 b8 fb ff ff ff e9 13 a9 31 f9 <b9> fb ff ff ff 31 c0 31 d2 e9 33 a9 31 f9 31 db e9 2a 0b 42 f9 31
RSP: 0018:ffffc90004a87a30 EFLAGS: 00010212
RAX: 0000000000040000 RBX: ffff88809cca4080 RCX: 0000000000000122
RDX: 00000000000063ff RSI: ffffc90004a87a98 RDI: 0000000000000122
RBP: 0000000000000122 R08: ffff888058486480 R09: fffffbfff131f481
R10: ffffffff898fa403 R11: fffffbfff131f480 R12: 0000000000000122
R13: 0000000000000078 R14: 0000000000000006 R15: ffffffff88244b5c
paravirt_read_msr_safe arch/x86/include/asm/paravirt.h:178 [inline]
vmx_create_vcpu+0x184/0x2b40 arch/x86/kvm/vmx/vmx.c:6827
kvm_arch_vcpu_create+0x6a8/0xb30 arch/x86/kvm/x86.c:9427
kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3043 [inline]
kvm_vm_ioctl+0x15b7/0x2460 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3603
vfs_ioctl fs/ioctl.c:48 [inline]
ksys_ioctl+0x11a/0x180 fs/ioctl.c:753
__do_sys_ioctl fs/ioctl.c:762 [inline]
__se_sys_ioctl fs/ioctl.c:760 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:353
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ca29
Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2c93b11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004e73c0 RCX: 000000000045ca29
RDX: 0000000000000000 RSI: 000000000000ae41 RDI: 0000000000000004
RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000396 R14: 00000000004c62c6 R15: 00007f2c93b126d4
=============================
WARNING: suspicious RCU usage
5.7.0-rc7-next-20200525-syzkaller #0 Not tainted
-----------------------------
include/trace/events/sched.h:629 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
RCU used illegally from idle CPU!
rcu_scheduler_active = 2, debug_locks = 0
RCU used illegally from extended quiescent state!
1 lock held by syz-executor.5/24641:
#0: ffff8880ae737d58 (&rq->lock){-.-.}-{2:2}, at: rq_lock kernel/sched/sched.h:1263 [inline]
#0: ffff8880ae737d58 (&rq->lock){-.-.}-{2:2}, at: __schedule+0x233/0x1f70 kernel/sched/core.c:4068
stack backtrace:
CPU: 1 PID: 24641 Comm: syz-executor.5 Not tainted 5.7.0-rc7-next-20200525-syzkaller #0
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+0x18f/0x20d lib/dump_stack.c:118
trace_pelt_se_tp include/trace/events/sched.h:629 [inline]
trace_pelt_se_tp include/trace/events/sched.h:629 [inline]
__update_load_avg_se+0x75a/0xc90 kernel/sched/pelt.c:321
update_load_avg+0x178/0x1c60 kernel/sched/fair.c:3786
set_next_entity+0x295/0x880 kernel/sched/fair.c:4387
pick_next_task_fair+0x66f/0xc70 kernel/sched/fair.c:7045
pick_next_task kernel/sched/core.c:3975 [inline]
__schedule+0x375/0x1f70 kernel/sched/core.c:4090
preempt_schedule_irq+0xb0/0x150 kernel/sched/core.c:4380
idtentry_exit+0xb9/0xc0 arch/x86/entry/common.c:585
exc_general_protection+0x23d/0x520 arch/x86/kernel/traps.c:506
asm_exc_general_protection+0x1e/0x30 arch/x86/include/asm/idtentry.h:353
RIP: 0010:kvm_fastop_exception+0xb68/0xfe8
Code: f2 ff ff ff 48 31 db e9 fb c9 2a f9 b8 f2 ff ff ff 48 31 f6 e9 ff c9 2a f9 31 c0 e9 ec 2c 2b f9 b8 fb ff ff ff e9 13 a9 31 f9 <b9> fb ff ff ff 31 c0 31 d2 e9 33 a9 31 f9 31 db e9 2a 0b 42 f9 31
RSP: 0018:ffffc90004a87a30 EFLAGS: 00010212
RAX: 0000000000040000 RBX: ffff88809cca4080 RCX: 0000000000000122
RDX: 00000000000063ff RSI: ffffc90004a87a98 RDI: 0000000000000122
RBP: 0000000000000122 R08: ffff888058486480 R09: fffffbfff131f481
R10: ffffffff898fa403 R11: fffffbfff131f480 R12: 0000000000000122
R13: 0000000000000078 R14: 0000000000000006 R15: ffffffff88244b5c
paravirt_read_msr_safe arch/x86/include/asm/paravirt.h:178 [inline]
vmx_create_vcpu+0x184/0x2b40 arch/x86/kvm/vmx/vmx.c:6827
kvm_arch_vcpu_create+0x6a8/0xb30 arch/x86/kvm/x86.c:9427
kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3043 [inline]
kvm_vm_ioctl+0x15b7/0x2460 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3603
vfs_ioctl fs/ioctl.c:48 [inline]
ksys_ioctl+0x11a/0x180 fs/ioctl.c:753
__do_sys_ioctl fs/ioctl.c:762 [inline]
__se_sys_ioctl fs/ioctl.c:760 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:353
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ca29
Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2c93b11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004e73c0 RCX: 000000000045ca29
RDX: 0000000000000000 RSI: 000000000000ae41 RDI: 0000000000000004
RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000396 R14: 00000000004c62c6 R15: 00007f2c93b126d4
check_preemption_disabled: 3 callbacks suppressed
BUG: using smp_processor_id() in preemptible [00000000] code: syz-executor.5/24641
caller is rcu_nmi_enter+0x19/0x200 kernel/rcu/tree.c:823
CPU: 1 PID: 24641 Comm: syz-executor.5 Not tainted 5.7.0-rc7-next-20200525-syzkaller #0
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+0x18f/0x20d lib/dump_stack.c:118
check_preemption_disabled+0x20d/0x220 lib/smp_processor_id.c:48
rcu_nmi_enter+0x19/0x200 kernel/rcu/tree.c:823
kernel_text_address+0x99/0xe0 kernel/extable.c:143
__kernel_text_address+0x9/0x30 kernel/extable.c:105
unwind_get_return_address arch/x86/kernel/unwind_orc.c:317 [inline]
unwind_get_return_address+0x5a/0xa0 arch/x86/kernel/unwind_orc.c:312
arch_stack_walk+0x97/0xf0 arch/x86/kernel/stacktrace.c:26
stack_trace_save+0x8c/0xc0 kernel/stacktrace.c:123
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc mm/kasan/common.c:494 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:467
slab_post_alloc_hook mm/slab.h:586 [inline]
slab_alloc mm/slab.c:3320 [inline]
kmem_cache_alloc+0x11b/0x740 mm/slab.c:3484
__d_alloc+0x2a/0x920 fs/dcache.c:1709
d_alloc_pseudo+0x19/0x70 fs/dcache.c:1838
alloc_file_pseudo+0xc6/0x250 fs/file_table.c:226
anon_inode_getfile fs/anon_inodes.c:91 [inline]
anon_inode_getfile+0xc8/0x1f0 fs/anon_inodes.c:74
anon_inode_getfd+0x4c/0xa0 fs/anon_inodes.c:136
create_vcpu_fd arch/x86/kvm/../../../virt/kvm/kvm_main.c:2983 [inline]
kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3058 [inline]
kvm_vm_ioctl+0x1ab5/0x2460 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3603
vfs_ioctl fs/ioctl.c:48 [inline]
ksys_ioctl+0x11a/0x180 fs/ioctl.c:753
__do_sys_ioctl fs/ioctl.c:762 [inline]
__se_sys_ioctl fs/ioctl.c:760 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:353
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ca29
Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2c93b11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004e73c0 RCX: 000000000045ca29
RDX: 0000000000000000 RSI: 000000000000ae41 RDI: 0000000000000004
RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000396 R14: 00000000004c62c6 R15: 00007f2c93b126d4
BUG: using smp_processor_id() in preemptible [00000000] code: syz-executor.5/24641
caller is rcu_dynticks_curr_cpu_in_eqs kernel/rcu/tree.c:299 [inline]
caller is rcu_nmi_enter+0x7b/0x200 kernel/rcu/tree.c:838
CPU: 1 PID: 24641 Comm: syz-executor.5 Not tainted 5.7.0-rc7-next-20200525-syzkaller #0
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+0x18f/0x20d lib/dump_stack.c:118
check_preemption_disabled+0x20d/0x220 lib/smp_processor_id.c:48
rcu_dynticks_curr_cpu_in_eqs kernel/rcu/tree.c:299 [inline]
rcu_nmi_enter+0x7b/0x200 kernel/rcu/tree.c:838
kernel_text_address+0x99/0xe0 kernel/extable.c:143
__kernel_text_address+0x9/0x30 kernel/extable.c:105
unwind_get_return_address arch/x86/kernel/unwind_orc.c:317 [inline]
unwind_get_return_address+0x5a/0xa0 arch/x86/kernel/unwind_orc.c:312
arch_stack_walk+0x97/0xf0 arch/x86/kernel/stacktrace.c:26
stack_trace_save+0x8c/0xc0 kernel/stacktrace.c:123
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc mm/kasan/common.c:494 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:467
slab_post_alloc_hook mm/slab.h:586 [inline]
slab_alloc mm/slab.c:3320 [inline]
kmem_cache_alloc+0x11b/0x740 mm/slab.c:3484
__d_alloc+0x2a/0x920 fs/dcache.c:1709
d_alloc_pseudo+0x19/0x70 fs/dcache.c:1838
alloc_file_pseudo+0xc6/0x250 fs/file_table.c:226
anon_inode_getfile fs/anon_inodes.c:91 [inline]
anon_inode_getfile+0xc8/0x1f0 fs/anon_inodes.c:74
anon_inode_getfd+0x4c/0xa0 fs/anon_inodes.c:136
create_vcpu_fd arch/x86/kvm/../../../virt/kvm/kvm_main.c:2983 [inline]
kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3058 [inline]
kvm_vm_ioctl+0x1ab5/0x2460 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3603
vfs_ioctl fs/ioctl.c:48 [inline]
ksys_ioctl+0x11a/0x180 fs/ioctl.c:753
__do_sys_ioctl fs/ioctl.c:762 [inline]
__se_sys_ioctl fs/ioctl.c:760 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:353
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ca29
Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2c93b11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004e73c0 RCX: 000000000045ca29
RDX: 0000000000000000 RSI: 000000000000ae41 RDI: 0000000000000004
RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000396 R14: 00000000004c62c6 R15: 00007f2c93b126d4
BUG: using smp_processor_id() in preemptible [00000000] code: syz-executor.5/24641
caller is rcu_dynticks_eqs_enter+0x11/0x70 kernel/rcu/tree.c:236
CPU: 1 PID: 24641 Comm: syz-executor.5 Not tainted 5.7.0-rc7-next-20200525-syzkaller #0
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+0x18f/0x20d lib/dump_stack.c:118
check_preemption_disabled+0x20d/0x220 lib/smp_processor_id.c:48
rcu_dynticks_eqs_enter+0x11/0x70 kernel/rcu/tree.c:236
rcu_nmi_enter+0x185/0x200 kernel/rcu/tree.c:844
kernel_text_address+0x99/0xe0 kernel/extable.c:143
__kernel_text_address+0x9/0x30 kernel/extable.c:105
unwind_get_return_address arch/x86/kernel/unwind_orc.c:317 [inline]
unwind_get_return_address+0x5a/0xa0 arch/x86/kernel/unwind_orc.c:312
arch_stack_walk+0x97/0xf0 arch/x86/kernel/stacktrace.c:26
stack_trace_save+0x8c/0xc0 kernel/stacktrace.c:123
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc mm/kasan/common.c:494 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:467
slab_post_alloc_hook mm/slab.h:586 [inline]
slab_alloc mm/slab.c:3320 [inline]
kmem_cache_alloc+0x11b/0x740 mm/slab.c:3484
__d_alloc+0x2a/0x920 fs/dcache.c:1709
d_alloc_pseudo+0x19/0x70 fs/dcache.c:1838
alloc_file_pseudo+0xc6/0x250 fs/file_table.c:226
anon_inode_getfile fs/anon_inodes.c:91 [inline]
anon_inode_getfile+0xc8/0x1f0 fs/anon_inodes.c:74
anon_inode_getfd+0x4c/0xa0 fs/anon_inodes.c:136
create_vcpu_fd arch/x86/kvm/../../../virt/kvm/kvm_main.c:2983 [inline]
kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3058 [inline]
kvm_vm_ioctl+0x1ab5/0x2460 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3603
vfs_ioctl fs/ioctl.c:48 [inline]
ksys_ioctl+0x11a/0x180 fs/ioctl.c:753
__do_sys_ioctl fs/ioctl.c:762 [inline]
__se_sys_ioctl fs/ioctl.c:760 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:353
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ca29
Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2c93b11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004e73c0 RCX: 000000000045ca29
RDX: 0000000000000000 RSI: 000000000000ae41 RDI: 0000000000000004
RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000396 R14: 00000000004c62c6 R15: 00007f2c93b126d4
BUG: using smp_processor_id() in preemptible [00000000] code: syz-executor.5/24641
caller is rcu_nmi_exit+0x19/0x2c0 kernel/rcu/tree.c:634
CPU: 1 PID: 24641 Comm: syz-executor.5 Not tainted 5.7.0-rc7-next-20200525-syzkaller #0
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+0x18f/0x20d lib/dump_stack.c:118
check_preemption_disabled+0x20d/0x220 lib/smp_processor_id.c:48
rcu_nmi_exit+0x19/0x2c0 kernel/rcu/tree.c:634
kernel_text_address+0xb3/0xe0 kernel/extable.c:156
__kernel_text_address+0x9/0x30 kernel/extable.c:105
unwind_get_return_address arch/x86/kernel/unwind_orc.c:317 [inline]
unwind_get_return_address+0x5a/0xa0 arch/x86/kernel/unwind_orc.c:312
arch_stack_walk+0x97/0xf0 arch/x86/kernel/stacktrace.c:26
stack_trace_save+0x8c/0xc0 kernel/stacktrace.c:123
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc mm/kasan/common.c:494 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:467
slab_post_alloc_hook mm/slab.h:586 [inline]
slab_alloc mm/slab.c:3320 [inline]
kmem_cache_alloc+0x11b/0x740 mm/slab.c:3484
__d_alloc+0x2a/0x920 fs/dcache.c:1709
d_alloc_pseudo+0x19/0x70 fs/dcache.c:1838
alloc_file_pseudo+0xc6/0x250 fs/file_table.c:226
anon_inode_getfile fs/anon_inodes.c:91 [inline]
anon_inode_getfile+0xc8/0x1f0 fs/anon_inodes.c:74
anon_inode_getfd+0x4c/0xa0 fs/anon_inodes.c:136
create_vcpu_fd arch/x86/kvm/../../../virt/kvm/kvm_main.c:2983 [inline]
kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3058 [inline]
kvm_vm_ioctl+0x1ab5/0x2460 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3603
vfs_ioctl fs/ioctl.c:48 [inline]
ksys_ioctl+0x11a/0x180 fs/ioctl.c:753
__do_sys_ioctl fs/ioctl.c:762 [inline]
__se_sys_ioctl fs/ioctl.c:760 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:353
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ca29
Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2c93b11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004e73c0 RCX: 000000000045ca29
RDX: 0000000000000000 RSI: 000000000000ae41 RDI: 0000000000000004
RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000396 R14: 00000000004c62c6 R15: 00007f2c93b126d4
BUG: using smp_processor_id() in preemptible [00000000] code: syz-executor.5/24641
caller is rcu_dynticks_curr_cpu_in_eqs kernel/rcu/tree.c:299 [inline]
caller is rcu_nmi_exit+0x7b/0x2c0 kernel/rcu/tree.c:642
CPU: 1 PID: 24641 Comm: syz-executor.5 Not tainted 5.7.0-rc7-next-20200525-syzkaller #0
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+0x18f/0x20d lib/dump_stack.c:118
check_preemption_disabled+0x20d/0x220 lib/smp_processor_id.c:48
rcu_dynticks_curr_cpu_in_eqs kernel/rcu/tree.c:299 [inline]
rcu_nmi_exit+0x7b/0x2c0 kernel/rcu/tree.c:642
kernel_text_address+0xb3/0xe0 kernel/extable.c:156
__kernel_text_address+0x9/0x30 kernel/extable.c:105
unwind_get_return_address arch/x86/kernel/unwind_orc.c:317 [inline]
unwind_get_return_address+0x5a/0xa0 arch/x86/kernel/unwind_orc.c:312
arch_stack_walk+0x97/0xf0 arch/x86/kernel/stacktrace.c:26
stack_trace_save+0x8c/0xc0 kernel/stacktrace.c:123
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc mm/kasan/common.c:494 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:467
slab_post_alloc_hook mm/slab.h:586 [inline]
slab_alloc mm/slab.c:3320 [inline]
kmem_cache_alloc+0x11b/0x740 mm/slab.c:3484
__d_alloc+0x2a/0x920 fs/dcache.c:1709
d_alloc_pseudo+0x19/0x70 fs/dcache.c:1838
alloc_file_pseudo+0xc6/0x250 fs/file_table.c:226
anon_inode_getfile fs/anon_inodes.c:91 [inline]
anon_inode_getfile+0xc8/0x1f0 fs/anon_inodes.c:74
anon_inode_getfd+0x4c/0xa0 fs/anon_inodes.c:136
create_vcpu_fd arch/x86/kvm/../../../virt/kvm/kvm_main.c:2983 [inline]
kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3058 [inline]
kvm_vm_ioctl+0x1ab5/0x2460 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3603
vfs_ioctl fs/ioctl.c:48 [inline]
ksys_ioctl+0x11a/0x180 fs/ioctl.c:753
__do_sys_ioctl fs/ioctl.c:762 [inline]
__se_sys_ioctl fs/ioctl.c:760 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:353
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ca29
Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2c93b11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004e73c0 RCX: 000000000045ca29
RDX: 0000000000000000 RSI: 000000000000ae41 RDI: 0000000000000004
RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000396 R14: 00000000004c62c6 R15: 00007f2c93b126d4
BUG: using smp_processor_id() in preemptible [00000000] code: syz-executor.5/24641
caller is rcu_dynticks_eqs_enter+0x11/0x70 kernel/rcu/tree.c:236
CPU: 1 PID: 24641 Comm: syz-executor.5 Not tainted 5.7.0-rc7-next-20200525-syzkaller #0
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+0x18f/0x20d lib/dump_stack.c:118
check_preemption_disabled+0x20d/0x220 lib/smp_processor_id.c:48
rcu_dynticks_eqs_enter+0x11/0x70 kernel/rcu/tree.c:236
rcu_nmi_exit+0x214/0x2c0 kernel/rcu/tree.c:670
kernel_text_address+0xb3/0xe0 kernel/extable.c:156
__kernel_text_address+0x9/0x30 kernel/extable.c:105
unwind_get_return_address arch/x86/kernel/unwind_orc.c:317 [inline]
unwind_get_return_address+0x5a/0xa0 arch/x86/kernel/unwind_orc.c:312
arch_stack_walk+0x97/0xf0 arch/x86/kernel/stacktrace.c:26
stack_trace_save+0x8c/0xc0 kernel/stacktrace.c:123
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc mm/kasan/common.c:494 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:467
slab_post_alloc_hook mm/slab.h:586 [inline]
slab_alloc mm/slab.c:3320 [inline]
kmem_cache_alloc+0x11b/0x740 mm/slab.c:3484
__d_alloc+0x2a/0x920 fs/dcache.c:1709
d_alloc_pseudo+0x19/0x70 fs/dcache.c:1838
alloc_file_pseudo+0xc6/0x250 fs/file_table.c:226
anon_inode_getfile fs/anon_inodes.c:91 [inline]
anon_inode_getfile+0xc8/0x1f0 fs/anon_inodes.c:74
anon_inode_getfd+0x4c/0xa0 fs/anon_inodes.c:136
create_vcpu_fd arch/x86/kvm/../../../virt/kvm/kvm_main.c:2983 [inline]
kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3058 [inline]
kvm_vm_ioctl+0x1ab5/0x2460 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3603
vfs_ioctl fs/ioctl.c:48 [inline]
ksys_ioctl+0x11a/0x180 fs/ioctl.c:753
__do_sys_ioctl fs/ioctl.c:762 [inline]
__se_sys_ioctl fs/ioctl.c:760 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:353
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ca29
Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2c93b11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004e73c0 RCX: 000000000045ca29
RDX: 0000000000000000 RSI: 000000000000ae41 RDI: 0000000000000004
RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000396 R14: 00000000004c62c6 R15: 00007f2c93b126d4
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: WARNING: suspicious RCU usage in idtentry_exit 2020-05-26 3:54 WARNING: suspicious RCU usage in idtentry_exit syzbot @ 2020-05-28 13:33 ` Thomas Gleixner 2020-05-28 16:11 ` Paul E. McKenney 2020-07-31 9:23 ` [tip: core/rcu] lockdep: Complain only once about RCU in extended quiescent state tip-bot2 for Paul E. McKenney 0 siblings, 2 replies; 11+ messages in thread From: Thomas Gleixner @ 2020-05-28 13:33 UTC (permalink / raw) To: syzbot Cc: Paolo Bonzini, Paul E. McKenney, bp, hpa, linux-kernel, luto, mingo, syzkaller-bugs, x86 syzbot <syzbot+3ae5eaae0809ee311e75@syzkaller.appspotmail.com> writes: + Paolo, Paul > syzbot found the following crash on: > > HEAD commit: 7b4cb0a4 Add linux-next specific files for 20200525 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=13356016100000 > kernel config: https://syzkaller.appspot.com/x/.config?x=47b0740d89299c10 > dashboard link: https://syzkaller.appspot.com/bug?extid=3ae5eaae0809ee311e75 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+3ae5eaae0809ee311e75@syzkaller.appspotmail.com > > ============================= > WARNING: suspicious RCU usage > 5.7.0-rc7-next-20200525-syzkaller #0 Not tainted > ----------------------------- > kernel/rcu/tree.c:715 RCU dynticks_nesting counter underflow/zero!! > > other info that might help us debug this: > > > RCU used illegally from idle CPU! > rcu_scheduler_active = 2, debug_locks = 1 > RCU used illegally from extended quiescent state! > no locks held by syz-executor.5/24641. > > stack backtrace: > CPU: 1 PID: 24641 Comm: syz-executor.5 Not tainted 5.7.0-rc7-next-20200525-syzkaller #0 > 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+0x18f/0x20d lib/dump_stack.c:118 > rcu_irq_exit_preempt+0x1fa/0x250 kernel/rcu/tree.c:715 > idtentry_exit+0x9e/0xc0 arch/x86/entry/common.c:583 > exc_general_protection+0x23d/0x520 arch/x86/kernel/traps.c:506 > asm_exc_general_protection+0x1e/0x30 arch/x86/include/asm/idtentry.h:353 > RIP: 0010:kvm_fastop_exception+0xb68/0xfe8 > Code: f2 ff ff ff 48 31 db e9 fb c9 2a f9 b8 f2 ff ff ff 48 31 f6 e9 ff c9 2a f9 31 c0 e9 ec 2c 2b f9 b8 fb ff ff ff e9 13 a9 31 f9 <b9> fb ff ff ff 31 c0 31 d2 e9 33 a9 31 f9 31 db e9 2a 0b 42 f9 31 > RSP: 0018:ffffc90004a87a30 EFLAGS: 00010212 > RAX: 0000000000040000 RBX: ffff88809cca4080 RCX: 0000000000000122 > RDX: 00000000000063ff RSI: ffffc90004a87a98 RDI: 0000000000000122 > RBP: 0000000000000122 R08: ffff888058486480 R09: fffffbfff131f481 > R10: ffffffff898fa403 R11: fffffbfff131f480 R12: 0000000000000122 > R13: 0000000000000078 R14: 0000000000000006 R15: ffffffff88244b5c > paravirt_read_msr_safe arch/x86/include/asm/paravirt.h:178 [inline] > vmx_create_vcpu+0x184/0x2b40 arch/x86/kvm/vmx/vmx.c:6827 > kvm_arch_vcpu_create+0x6a8/0xb30 arch/x86/kvm/x86.c:9427 > kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3043 [inline] > kvm_vm_ioctl+0x15b7/0x2460 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3603 > vfs_ioctl fs/ioctl.c:48 [inline] > ksys_ioctl+0x11a/0x180 fs/ioctl.c:753 > __do_sys_ioctl fs/ioctl.c:762 [inline] > __se_sys_ioctl fs/ioctl.c:760 [inline] > __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760 > do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:353 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x45ca29 > Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:00007f2c93b11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > RAX: ffffffffffffffda RBX: 00000000004e73c0 RCX: 000000000045ca29 > RDX: 0000000000000000 RSI: 000000000000ae41 RDI: 0000000000000004 > RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff > R13: 0000000000000396 R14: 00000000004c62c6 R15: 00007f2c93b126d4 Weird. I have no idea how that thing is an EQS here. Thanks, tglx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING: suspicious RCU usage in idtentry_exit 2020-05-28 13:33 ` Thomas Gleixner @ 2020-05-28 16:11 ` Paul E. McKenney 2020-05-28 20:19 ` Thomas Gleixner 2020-07-31 9:23 ` [tip: core/rcu] lockdep: Complain only once about RCU in extended quiescent state tip-bot2 for Paul E. McKenney 1 sibling, 1 reply; 11+ messages in thread From: Paul E. McKenney @ 2020-05-28 16:11 UTC (permalink / raw) To: Thomas Gleixner Cc: syzbot, Paolo Bonzini, bp, hpa, linux-kernel, luto, mingo, syzkaller-bugs, x86 On Thu, May 28, 2020 at 03:33:44PM +0200, Thomas Gleixner wrote: > syzbot <syzbot+3ae5eaae0809ee311e75@syzkaller.appspotmail.com> writes: > > + Paolo, Paul > > > syzbot found the following crash on: > > > > HEAD commit: 7b4cb0a4 Add linux-next specific files for 20200525 > > git tree: linux-next > > console output: https://syzkaller.appspot.com/x/log.txt?x=13356016100000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=47b0740d89299c10 > > dashboard link: https://syzkaller.appspot.com/bug?extid=3ae5eaae0809ee311e75 > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+3ae5eaae0809ee311e75@syzkaller.appspotmail.com > > > > ============================= > > WARNING: suspicious RCU usage > > 5.7.0-rc7-next-20200525-syzkaller #0 Not tainted > > ----------------------------- > > kernel/rcu/tree.c:715 RCU dynticks_nesting counter underflow/zero!! So the nesting counter overflowed or got clobbered to either zero or some negative number. The usual cause of this is a misnesting of rcu_nmi_enter() and rcu_nmi_exit(). If this were reproducible, I would suggest tracking this down by enabling the rcu_dyntick trace event. :-/ > > other info that might help us debug this: > > > > > > RCU used illegally from idle CPU! This might indicate that the aforementioned mismatch was having invoked rcu_nmi_exit() in an exception that never invoked rcu_nmi_enter(). In this case, the lack of the rcu_nmi_enter() would leave the CPU looking idle to RCU, and then the call to rcu_nmi_exit() would result in a negative counter. But I would have expected a pair of earlier splats from rcu_nmi_exit() in that case: WARN_ON_ONCE(rdp->dynticks_nesting <= 0); WARN_ON_ONCE(rcu_dynticks_curr_cpu_in_eqs()); So another hypothesis is that neither rcu_nmi_enter() nor rcu_nmi_exit() were invoked, leaving the ->dynticks_nesting counter at the value zero, in turn causing rcu_irq_exit_preempt() to complain. > > rcu_scheduler_active = 2, debug_locks = 1 > > RCU used illegally from extended quiescent state! Huh. This is a bit repetitive, isn't it? I just queued a patch to say this only once. </distraction> > > no locks held by syz-executor.5/24641. > > > > stack backtrace: > > CPU: 1 PID: 24641 Comm: syz-executor.5 Not tainted 5.7.0-rc7-next-20200525-syzkaller #0 > > 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+0x18f/0x20d lib/dump_stack.c:118 > > rcu_irq_exit_preempt+0x1fa/0x250 kernel/rcu/tree.c:715 > > idtentry_exit+0x9e/0xc0 arch/x86/entry/common.c:583 > > exc_general_protection+0x23d/0x520 arch/x86/kernel/traps.c:506 > > asm_exc_general_protection+0x1e/0x30 arch/x86/include/asm/idtentry.h:353 > > RIP: 0010:kvm_fastop_exception+0xb68/0xfe8 > > Code: f2 ff ff ff 48 31 db e9 fb c9 2a f9 b8 f2 ff ff ff 48 31 f6 e9 ff c9 2a f9 31 c0 e9 ec 2c 2b f9 b8 fb ff ff ff e9 13 a9 31 f9 <b9> fb ff ff ff 31 c0 31 d2 e9 33 a9 31 f9 31 db e9 2a 0b 42 f9 31 > > RSP: 0018:ffffc90004a87a30 EFLAGS: 00010212 > > RAX: 0000000000040000 RBX: ffff88809cca4080 RCX: 0000000000000122 > > RDX: 00000000000063ff RSI: ffffc90004a87a98 RDI: 0000000000000122 > > RBP: 0000000000000122 R08: ffff888058486480 R09: fffffbfff131f481 > > R10: ffffffff898fa403 R11: fffffbfff131f480 R12: 0000000000000122 > > R13: 0000000000000078 R14: 0000000000000006 R15: ffffffff88244b5c > > paravirt_read_msr_safe arch/x86/include/asm/paravirt.h:178 [inline] > > vmx_create_vcpu+0x184/0x2b40 arch/x86/kvm/vmx/vmx.c:6827 > > kvm_arch_vcpu_create+0x6a8/0xb30 arch/x86/kvm/x86.c:9427 > > kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3043 [inline] > > kvm_vm_ioctl+0x15b7/0x2460 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3603 > > vfs_ioctl fs/ioctl.c:48 [inline] > > ksys_ioctl+0x11a/0x180 fs/ioctl.c:753 > > __do_sys_ioctl fs/ioctl.c:762 [inline] > > __se_sys_ioctl fs/ioctl.c:760 [inline] > > __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760 > > do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:353 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > RIP: 0033:0x45ca29 > > Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > > RSP: 002b:00007f2c93b11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > > RAX: ffffffffffffffda RBX: 00000000004e73c0 RCX: 000000000045ca29 > > RDX: 0000000000000000 RSI: 000000000000ae41 RDI: 0000000000000004 > > RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000 > > R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff > > R13: 0000000000000396 R14: 00000000004c62c6 R15: 00007f2c93b126d4 > > Weird. I have no idea how that thing is an EQS here. No argument on the "Weird" part! ;-) Is this a NO_HZ_FULL=y kernel? If so, one possibility is that the call to rcu_user_exit() went missing somehow. If not, then RCU should have been watching userspace execution. Again, the only thing I can think of (should this prove to be reproducible) is the rcu_dyntick trace event. Thanx, Paul ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING: suspicious RCU usage in idtentry_exit 2020-05-28 16:11 ` Paul E. McKenney @ 2020-05-28 20:19 ` Thomas Gleixner 2020-05-28 20:48 ` Paul E. McKenney 0 siblings, 1 reply; 11+ messages in thread From: Thomas Gleixner @ 2020-05-28 20:19 UTC (permalink / raw) To: paulmck Cc: syzbot, Paolo Bonzini, bp, hpa, linux-kernel, luto, mingo, syzkaller-bugs, x86 Paul, "Paul E. McKenney" <paulmck@kernel.org> writes: > On Thu, May 28, 2020 at 03:33:44PM +0200, Thomas Gleixner wrote: >> syzbot <syzbot+3ae5eaae0809ee311e75@syzkaller.appspotmail.com> writes: >> Weird. I have no idea how that thing is an EQS here. > > No argument on the "Weird" part! ;-) > > Is this a NO_HZ_FULL=y kernel? No, it has only NO_HZ_IDLE. https://syzkaller.appspot.com/x/.config?x=47b0740d89299c10 > If so, one possibility is that the call > to rcu_user_exit() went missing somehow. If not, then RCU should have > been watching userspace execution. > > Again, the only thing I can think of (should this prove to be > reproducible) is the rcu_dyntick trace event. :) Thanks, tglx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING: suspicious RCU usage in idtentry_exit 2020-05-28 20:19 ` Thomas Gleixner @ 2020-05-28 20:48 ` Paul E. McKenney 2020-05-29 6:20 ` Dmitry Vyukov 0 siblings, 1 reply; 11+ messages in thread From: Paul E. McKenney @ 2020-05-28 20:48 UTC (permalink / raw) To: Thomas Gleixner Cc: syzbot, Paolo Bonzini, bp, hpa, linux-kernel, luto, mingo, syzkaller-bugs, x86 On Thu, May 28, 2020 at 10:19:02PM +0200, Thomas Gleixner wrote: > Paul, > > "Paul E. McKenney" <paulmck@kernel.org> writes: > > On Thu, May 28, 2020 at 03:33:44PM +0200, Thomas Gleixner wrote: > >> syzbot <syzbot+3ae5eaae0809ee311e75@syzkaller.appspotmail.com> writes: > >> Weird. I have no idea how that thing is an EQS here. > > > > No argument on the "Weird" part! ;-) > > > > Is this a NO_HZ_FULL=y kernel? > > No, it has only NO_HZ_IDLE. > > https://syzkaller.appspot.com/x/.config?x=47b0740d89299c10 OK, from the .config, another suggestion is to build the kernel with CONFIG_RCU_EQS_DEBUG=y. This still requires that this issue be reproduced, but it might catch the problem earlier. > > If so, one possibility is that the call > > to rcu_user_exit() went missing somehow. If not, then RCU should have > > been watching userspace execution. > > > > Again, the only thing I can think of (should this prove to be > > reproducible) is the rcu_dyntick trace event. > > :) > > Thanks, > > tglx Thanx, Paul ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING: suspicious RCU usage in idtentry_exit 2020-05-28 20:48 ` Paul E. McKenney @ 2020-05-29 6:20 ` Dmitry Vyukov 2020-05-29 8:51 ` Thomas Gleixner 2020-05-29 14:05 ` Paul E. McKenney 0 siblings, 2 replies; 11+ messages in thread From: Dmitry Vyukov @ 2020-05-29 6:20 UTC (permalink / raw) To: Paul E. McKenney Cc: Thomas Gleixner, syzbot, Paolo Bonzini, Borislav Petkov, H. Peter Anvin, LKML, Andy Lutomirski, Ingo Molnar, syzkaller-bugs, the arch/x86 maintainers On Thu, May 28, 2020 at 10:48 PM Paul E. McKenney <paulmck@kernel.org> wrote: > > On Thu, May 28, 2020 at 10:19:02PM +0200, Thomas Gleixner wrote: > > Paul, > > > > "Paul E. McKenney" <paulmck@kernel.org> writes: > > > On Thu, May 28, 2020 at 03:33:44PM +0200, Thomas Gleixner wrote: > > >> syzbot <syzbot+3ae5eaae0809ee311e75@syzkaller.appspotmail.com> writes: > > >> Weird. I have no idea how that thing is an EQS here. > > > > > > No argument on the "Weird" part! ;-) > > > > > > Is this a NO_HZ_FULL=y kernel? > > > > No, it has only NO_HZ_IDLE. > > > > https://syzkaller.appspot.com/x/.config?x=47b0740d89299c10 > > OK, from the .config, another suggestion is to build the kernel > with CONFIG_RCU_EQS_DEBUG=y. This still requires that this issue be > reproduced, but it might catch the problem earlier. How much does it slow down execution? If we enable it on syzbot, it will affect all fuzzing done by syzbot always. It can tolerate significant slowdown and it's far from a production kernel (it enables KASAN, KCOV, LOCKDEP and more). But I am still asking because some debugging features are built without performance in mind at all (like let's just drop a global lock in every kmalloc/free, which may be too much even for a standard debug build). > > > If so, one possibility is that the call > > > to rcu_user_exit() went missing somehow. If not, then RCU should have > > > been watching userspace execution. > > > > > > Again, the only thing I can think of (should this prove to be > > > reproducible) is the rcu_dyntick trace event. > > > > :) > > > > Thanks, > > > > tglx > > Thanx, Paul > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20200528204839.GR2869%40paulmck-ThinkPad-P72. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING: suspicious RCU usage in idtentry_exit 2020-05-29 6:20 ` Dmitry Vyukov @ 2020-05-29 8:51 ` Thomas Gleixner 2020-05-29 14:05 ` Paul E. McKenney 1 sibling, 0 replies; 11+ messages in thread From: Thomas Gleixner @ 2020-05-29 8:51 UTC (permalink / raw) To: Dmitry Vyukov, Paul E. McKenney Cc: syzbot, Paolo Bonzini, Borislav Petkov, H. Peter Anvin, LKML, Andy Lutomirski, Ingo Molnar, syzkaller-bugs, the arch/x86 maintainers Dmitry, Dmitry Vyukov <dvyukov@google.com> writes: > On Thu, May 28, 2020 at 10:48 PM Paul E. McKenney <paulmck@kernel.org> wrote: >> On Thu, May 28, 2020 at 10:19:02PM +0200, Thomas Gleixner wrote: >> OK, from the .config, another suggestion is to build the kernel >> with CONFIG_RCU_EQS_DEBUG=y. This still requires that this issue be >> reproduced, but it might catch the problem earlier. > > How much does it slow down execution? If we enable it on syzbot, it > will affect all fuzzing done by syzbot always. > It can tolerate significant slowdown and it's far from a production > kernel (it enables KASAN, KCOV, LOCKDEP and more). But I am still > asking because some debugging features are built without performance > in mind at all (like let's just drop a global lock in every > kmalloc/free, which may be too much even for a standard debug build). It's not worse than lockdep. Thanks, tglx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING: suspicious RCU usage in idtentry_exit 2020-05-29 6:20 ` Dmitry Vyukov 2020-05-29 8:51 ` Thomas Gleixner @ 2020-05-29 14:05 ` Paul E. McKenney 2020-05-29 14:32 ` Dmitry Vyukov 1 sibling, 1 reply; 11+ messages in thread From: Paul E. McKenney @ 2020-05-29 14:05 UTC (permalink / raw) To: Dmitry Vyukov Cc: Thomas Gleixner, syzbot, Paolo Bonzini, Borislav Petkov, H. Peter Anvin, LKML, Andy Lutomirski, Ingo Molnar, syzkaller-bugs, the arch/x86 maintainers On Fri, May 29, 2020 at 08:20:12AM +0200, Dmitry Vyukov wrote: > On Thu, May 28, 2020 at 10:48 PM Paul E. McKenney <paulmck@kernel.org> wrote: > > > > On Thu, May 28, 2020 at 10:19:02PM +0200, Thomas Gleixner wrote: > > > Paul, > > > > > > "Paul E. McKenney" <paulmck@kernel.org> writes: > > > > On Thu, May 28, 2020 at 03:33:44PM +0200, Thomas Gleixner wrote: > > > >> syzbot <syzbot+3ae5eaae0809ee311e75@syzkaller.appspotmail.com> writes: > > > >> Weird. I have no idea how that thing is an EQS here. > > > > > > > > No argument on the "Weird" part! ;-) > > > > > > > > Is this a NO_HZ_FULL=y kernel? > > > > > > No, it has only NO_HZ_IDLE. > > > > > > https://syzkaller.appspot.com/x/.config?x=47b0740d89299c10 > > > > OK, from the .config, another suggestion is to build the kernel > > with CONFIG_RCU_EQS_DEBUG=y. This still requires that this issue be > > reproduced, but it might catch the problem earlier. > > How much does it slow down execution? If we enable it on syzbot, it > will affect all fuzzing done by syzbot always. > It can tolerate significant slowdown and it's far from a production > kernel (it enables KASAN, KCOV, LOCKDEP and more). But I am still > asking because some debugging features are built without performance > in mind at all (like let's just drop a global lock in every > kmalloc/free, which may be too much even for a standard debug build). It is an extra WARN_ON_ONCE() with a simple comparison, but on almost every kernel entry/exit path. So not something you want in production, but much lighter weight than any of the tools you listed above. Full disclosure: It usually fires for new architectures or for new timer hardware/drivers. Which might allow you to enable it selectively. Thanx, Paul > > > > If so, one possibility is that the call > > > > to rcu_user_exit() went missing somehow. If not, then RCU should have > > > > been watching userspace execution. > > > > > > > > Again, the only thing I can think of (should this prove to be > > > > reproducible) is the rcu_dyntick trace event. > > > > > > :) > > > > > > Thanks, > > > > > > tglx > > > > Thanx, Paul > > > > -- > > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. > > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20200528204839.GR2869%40paulmck-ThinkPad-P72. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING: suspicious RCU usage in idtentry_exit 2020-05-29 14:05 ` Paul E. McKenney @ 2020-05-29 14:32 ` Dmitry Vyukov 2020-05-29 16:07 ` Paul E. McKenney 0 siblings, 1 reply; 11+ messages in thread From: Dmitry Vyukov @ 2020-05-29 14:32 UTC (permalink / raw) To: Paul E. McKenney Cc: Thomas Gleixner, syzbot, Paolo Bonzini, Borislav Petkov, H. Peter Anvin, LKML, Andy Lutomirski, Ingo Molnar, syzkaller-bugs, the arch/x86 maintainers On Fri, May 29, 2020 at 4:05 PM Paul E. McKenney <paulmck@kernel.org> wrote: > > On Fri, May 29, 2020 at 08:20:12AM +0200, Dmitry Vyukov wrote: > > On Thu, May 28, 2020 at 10:48 PM Paul E. McKenney <paulmck@kernel.org> wrote: > > > > > > On Thu, May 28, 2020 at 10:19:02PM +0200, Thomas Gleixner wrote: > > > > Paul, > > > > > > > > "Paul E. McKenney" <paulmck@kernel.org> writes: > > > > > On Thu, May 28, 2020 at 03:33:44PM +0200, Thomas Gleixner wrote: > > > > >> syzbot <syzbot+3ae5eaae0809ee311e75@syzkaller.appspotmail.com> writes: > > > > >> Weird. I have no idea how that thing is an EQS here. > > > > > > > > > > No argument on the "Weird" part! ;-) > > > > > > > > > > Is this a NO_HZ_FULL=y kernel? > > > > > > > > No, it has only NO_HZ_IDLE. > > > > > > > > https://syzkaller.appspot.com/x/.config?x=47b0740d89299c10 > > > > > > OK, from the .config, another suggestion is to build the kernel > > > with CONFIG_RCU_EQS_DEBUG=y. This still requires that this issue be > > > reproduced, but it might catch the problem earlier. > > > > How much does it slow down execution? If we enable it on syzbot, it > > will affect all fuzzing done by syzbot always. > > It can tolerate significant slowdown and it's far from a production > > kernel (it enables KASAN, KCOV, LOCKDEP and more). But I am still > > asking because some debugging features are built without performance > > in mind at all (like let's just drop a global lock in every > > kmalloc/free, which may be too much even for a standard debug build). > > It is an extra WARN_ON_ONCE() with a simple comparison, but on almost > every kernel entry/exit path. > > So not something you want in production, but much lighter weight than > any of the tools you listed above. > > Full disclosure: It usually fires for new architectures or for new > timer hardware/drivers. Which might allow you to enable it selectively. This sounds reasonable. I've enabled it: https://github.com/google/syzkaller/commit/3905eaae004605f4ec4dab83e6883173796118c8 syzbot will pick up within a day or so. Then crashes will have any additional checks captured. The arch/hardware is quite old: x86_64/GCE. It also booted for me in qemu without warnings. > Thanx, Paul > > > > > > If so, one possibility is that the call > > > > > to rcu_user_exit() went missing somehow. If not, then RCU should have > > > > > been watching userspace execution. > > > > > > > > > > Again, the only thing I can think of (should this prove to be > > > > > reproducible) is the rcu_dyntick trace event. > > > > > > > > :) > > > > > > > > Thanks, > > > > > > > > tglx > > > > > > Thanx, Paul > > > > > > -- > > > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > > > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. > > > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20200528204839.GR2869%40paulmck-ThinkPad-P72. > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20200529140521.GA2869%40paulmck-ThinkPad-P72. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING: suspicious RCU usage in idtentry_exit 2020-05-29 14:32 ` Dmitry Vyukov @ 2020-05-29 16:07 ` Paul E. McKenney 0 siblings, 0 replies; 11+ messages in thread From: Paul E. McKenney @ 2020-05-29 16:07 UTC (permalink / raw) To: Dmitry Vyukov Cc: Thomas Gleixner, syzbot, Paolo Bonzini, Borislav Petkov, H. Peter Anvin, LKML, Andy Lutomirski, Ingo Molnar, syzkaller-bugs, the arch/x86 maintainers On Fri, May 29, 2020 at 04:32:31PM +0200, Dmitry Vyukov wrote: > On Fri, May 29, 2020 at 4:05 PM Paul E. McKenney <paulmck@kernel.org> wrote: > > > > On Fri, May 29, 2020 at 08:20:12AM +0200, Dmitry Vyukov wrote: > > > On Thu, May 28, 2020 at 10:48 PM Paul E. McKenney <paulmck@kernel.org> wrote: > > > > > > > > On Thu, May 28, 2020 at 10:19:02PM +0200, Thomas Gleixner wrote: > > > > > Paul, > > > > > > > > > > "Paul E. McKenney" <paulmck@kernel.org> writes: > > > > > > On Thu, May 28, 2020 at 03:33:44PM +0200, Thomas Gleixner wrote: > > > > > >> syzbot <syzbot+3ae5eaae0809ee311e75@syzkaller.appspotmail.com> writes: > > > > > >> Weird. I have no idea how that thing is an EQS here. > > > > > > > > > > > > No argument on the "Weird" part! ;-) > > > > > > > > > > > > Is this a NO_HZ_FULL=y kernel? > > > > > > > > > > No, it has only NO_HZ_IDLE. > > > > > > > > > > https://syzkaller.appspot.com/x/.config?x=47b0740d89299c10 > > > > > > > > OK, from the .config, another suggestion is to build the kernel > > > > with CONFIG_RCU_EQS_DEBUG=y. This still requires that this issue be > > > > reproduced, but it might catch the problem earlier. > > > > > > How much does it slow down execution? If we enable it on syzbot, it > > > will affect all fuzzing done by syzbot always. > > > It can tolerate significant slowdown and it's far from a production > > > kernel (it enables KASAN, KCOV, LOCKDEP and more). But I am still > > > asking because some debugging features are built without performance > > > in mind at all (like let's just drop a global lock in every > > > kmalloc/free, which may be too much even for a standard debug build). > > > > It is an extra WARN_ON_ONCE() with a simple comparison, but on almost > > every kernel entry/exit path. > > > > So not something you want in production, but much lighter weight than > > any of the tools you listed above. > > > > Full disclosure: It usually fires for new architectures or for new > > timer hardware/drivers. Which might allow you to enable it selectively. > > > This sounds reasonable. I've enabled it: > https://github.com/google/syzkaller/commit/3905eaae004605f4ec4dab83e6883173796118c8 > syzbot will pick up within a day or so. Then crashes will have any > additional checks captured. > > The arch/hardware is quite old: x86_64/GCE. It also booted for me in > qemu without warnings. Very good, thank you! Thanx, Paul > > > > > > If so, one possibility is that the call > > > > > > to rcu_user_exit() went missing somehow. If not, then RCU should have > > > > > > been watching userspace execution. > > > > > > > > > > > > Again, the only thing I can think of (should this prove to be > > > > > > reproducible) is the rcu_dyntick trace event. > > > > > > > > > > :) > > > > > > > > > > Thanks, > > > > > > > > > > tglx > > > > > > > > Thanx, Paul > > > > > > > > -- > > > > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > > > > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. > > > > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20200528204839.GR2869%40paulmck-ThinkPad-P72. > > > > -- > > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. > > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20200529140521.GA2869%40paulmck-ThinkPad-P72. ^ permalink raw reply [flat|nested] 11+ messages in thread
* [tip: core/rcu] lockdep: Complain only once about RCU in extended quiescent state 2020-05-28 13:33 ` Thomas Gleixner 2020-05-28 16:11 ` Paul E. McKenney @ 2020-07-31 9:23 ` tip-bot2 for Paul E. McKenney 1 sibling, 0 replies; 11+ messages in thread From: tip-bot2 for Paul E. McKenney @ 2020-07-31 9:23 UTC (permalink / raw) To: linux-tip-commits Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Paul E. McKenney, x86, LKML The following commit has been merged into the core/rcu branch of tip: Commit-ID: d29e0b26b020422cc51b5b51733cc50fcf443965 Gitweb: https://git.kernel.org/tip/d29e0b26b020422cc51b5b51733cc50fcf443965 Author: Paul E. McKenney <paulmck@kernel.org> AuthorDate: Thu, 28 May 2020 08:49:29 -07:00 Committer: Paul E. McKenney <paulmck@kernel.org> CommitterDate: Mon, 29 Jun 2020 11:58:51 -07:00 lockdep: Complain only once about RCU in extended quiescent state Currently, lockdep_rcu_suspicious() complains twice about RCU read-side critical sections being invoked from within extended quiescent states, for example: RCU used illegally from idle CPU! rcu_scheduler_active = 2, debug_locks = 1 RCU used illegally from extended quiescent state! This commit therefore saves a couple lines of code and one line of console-log output by eliminating the first of these two complaints. Link: https://lore.kernel.org/lkml/87wo4wnpzb.fsf@nanos.tec.linutronix.de Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> --- kernel/locking/lockdep.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 29a8de4..0a7549d 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -5851,9 +5851,7 @@ void lockdep_rcu_suspicious(const char *file, const int line, const char *s) pr_warn("\n%srcu_scheduler_active = %d, debug_locks = %d\n", !rcu_lockdep_current_cpu_online() ? "RCU used illegally from offline CPU!\n" - : !rcu_is_watching() - ? "RCU used illegally from idle CPU!\n" - : "", + : "", rcu_scheduler_active, debug_locks); /* ^ permalink raw reply related [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-07-31 9:24 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-26 3:54 WARNING: suspicious RCU usage in idtentry_exit syzbot 2020-05-28 13:33 ` Thomas Gleixner 2020-05-28 16:11 ` Paul E. McKenney 2020-05-28 20:19 ` Thomas Gleixner 2020-05-28 20:48 ` Paul E. McKenney 2020-05-29 6:20 ` Dmitry Vyukov 2020-05-29 8:51 ` Thomas Gleixner 2020-05-29 14:05 ` Paul E. McKenney 2020-05-29 14:32 ` Dmitry Vyukov 2020-05-29 16:07 ` Paul E. McKenney 2020-07-31 9:23 ` [tip: core/rcu] lockdep: Complain only once about RCU in extended quiescent state tip-bot2 for Paul E. McKenney
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.