On Wed, Jun 22, 2016 at 10:46 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > On 22/06/2016 10:38, Dmitry Vyukov wrote: >> On Wed, Jun 22, 2016 at 10:36 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >>> On 22/06/2016 10:20, Dmitry Vyukov wrote: >>>>>>>> All crashes suggest that apic is NULL. >>>>>>>> >>>>>>>> On commit b06f3a168cdcd80026276898fd1fee443ef25743 (Jan 6). >>>> >>>> Ping. Just hit it again on 67016f6cdfd079e632bbc49e33178b2d558c120a (Jun 20): >>> >>> This might have been the same bug you reported yesterday in kvm_set_cr8. >>> I've sent a patch to fix static keys. >> >> Then it is probably the same as the following one as well? > > Not 100% sure, can you send the reproducer? I can't directly reproduce this. When I tried I hit other known bugs, e.g.: BUG: KASAN: use-after-free in do_raw_spin_lock+0x281/0x2b0 at addr ffff8800606e0c64 Read of size 4 by task syz-executor/11240 page:ffffea000181b800 count:0 mapcount:-127 mapping: (null) index:0x0 flags: 0x4fffe0000000000() page dumped because: kasan: bad access detected CPU: 2 PID: 11240 Comm: syz-executor Tainted: G D 4.7.0-rc4+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffffffff880b58e0 ffff88004082f850 ffffffff82cc62cf ffffffff4082f8e0 fffffbfff1016b1c ffff88004082f8e0 ffff8800606e0c64 ffff8800606e0c98 ffff88006b31d6a8 ffff8800606e0c60 ffff88004082f8d0 ffffffff817bdfb2 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff82cc62cf>] dump_stack+0x12e/0x18f lib/dump_stack.c:51 [< inline >] print_address_description mm/kasan/report.c:191 [<ffffffff817bdfb2>] kasan_report_error+0x4e2/0x510 mm/kasan/report.c:276 [< inline >] kasan_report mm/kasan/report.c:298 [<ffffffff817be09e>] __asan_report_load4_noabort+0x3e/0x40 mm/kasan/report.c:318 [< inline >] debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [<ffffffff81484e81>] do_raw_spin_lock+0x281/0x2b0 kernel/locking/spinlock_debug.c:135 [< inline >] __raw_spin_lock_irq include/linux/spinlock_api_smp.h:131 [<ffffffff86a969ff>] _raw_spin_lock_irq+0x6f/0x80 kernel/locking/spinlock.c:167 [< inline >] spin_lock_irq include/linux/spinlock.h:332 [<ffffffff81073eff>] kvm_irqfd_release+0x2f/0x120 arch/x86/kvm/../../../virt/kvm/eventfd.c:584 [<ffffffff8105dfca>] kvm_vm_release+0x3a/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:752 [<ffffffff81819ee6>] __fput+0x236/0x780 fs/file_table.c:208 [<ffffffff8181a4b5>] ____fput+0x15/0x20 fs/file_table.c:244 [<ffffffff813d0826>] task_work_run+0xf6/0x170 kernel/task_work.c:115 [< inline >] exit_task_work include/linux/task_work.h:21 [<ffffffff8137aed2>] do_exit+0xa62/0x2c80 kernel/exit.c:748 [<ffffffff8137d268>] do_group_exit+0x108/0x330 kernel/exit.c:878 [<ffffffff813a0734>] get_signal+0x634/0x15e0 kernel/signal.c:2307 [<ffffffff811fa943>] do_signal+0x83/0x1f20 arch/x86/kernel/signal.c:783 [<ffffffff81006695>] exit_to_usermode_loop+0x1a5/0x210 arch/x86/entry/common.c:229 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:264 [<ffffffff8100885f>] syscall_return_slowpath+0x2bf/0x340 arch/x86/entry/common.c:329 [<ffffffff86a9709c>] entry_SYSCALL_64_fastpath+0xbf/0xc1 arch/x86/entry/entry_64.S:241 So probably it's induced by other bugs. I've looked at preempt_notifier_inc/preempt_notifier_dec calls, but I don't see any obvious bugs. I thought that maybe preempt_notifier_inc is called after installing fd into the file table, in which case another thread could do ioctl's on the fd before preempt_notifier_inc, but it does not seem to be the case. dup calls should also be properly handled, right? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
