On Thu, Oct 11, 2018 at 4:32 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > On 11/10/2018 04:57, Du Changbin wrote: >> I think the issue is that using vmx instructions after vmx off. The >> scenario is: >> 1. kernel is rebooting and vmx is turned off by notification handler >> kvm_reboot(), >> and 'kvm_rebooting' is set. >> 2. But there is a pending KVM_CREATE_VCPU ioctl which will invoke >> vmcs_clear()-> >> ____kvm_handle_fault_on_reboot()->kvm_spurious_fault()->BUG(). >> >> Need to improve the handler for such case so won't hang kernel. > > Why would the kernel be rebooting, given the reproducer (listed below my > signature, or at https://syzkaller.appspot.com/x/repro.c?x=131e37c9400000)? > > I think this is a duplicate of > > WARNING: refcount bug in kvm_vm_ioctl > BUG: unable to handle kernel paging request in > refcount_inc_not_zero_checked > > In all cases the refcounts seem to be broken, and kvm_destroy_kvm is > called prematurely (which in this case results in hardware_disable_all > being called, so that the vmclear fails). > > Dmitry, have such bugs been reported for subsystems other than KVM? We have _all_ types of bugs reported in _all_ subsystems. So you need to be more precise :) You can see all currently open bugs here: https://syzkaller.appspot.com/#upstream And here you can search over reports: https://groups.google.com/forum/#!forum/syzkaller-bugs E.g.: https://groups.google.com/forum/#!searchin/syzkaller-bugs/refcount_inc_not_zero_checked We had this recently, which is task_struct refcount bug: https://syzkaller.appspot.com/bug?id=e1854417677586ce3d00f498f19816cb4fd15676 but this seems to be related to rdma. And repro for this bug only deals with kvm. So my guess would be that this is a different bug in kvm. If you can reproduce it, then perhaps logging all refcount operation on the thing will help to find whoever releases a ref it does not own. > Paolo > > #syz dup: WARNING: refcount bug in kvm_vm_ioctl > >> # See https://goo.gl/kgGztJ for information about syzkaller reproducers. >> #{"threaded":true,"repeat":true,"procs":6,"sandbox":"","fault_call":-1,"tmpdir":true} >> r0 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000080)='/dev/kvm\x00', 0x0, 0x0) >> r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0) >> r2 = ioctl$KVM_CREATE_VCPU(r1, 0xae41, 0x0) >> ioctl$KVM_SET_VCPU_EVENTS(r2, 0x4040aea0, &(0x7f0000000000)={0x5, 0x7, 0x40, 0x0, 0x0, 0x0, 0x0, 0x492, 0x5, 0x1, 0xffff, 0x0, 0x0, 0xef, 0x100000000, 0x0, 0x100}) >> ioctl$KVM_SET_USER_MEMORY_REGION(r1, 0x4020ae46, &(0x7f0000000040)={0x0, 0x0, 0x0, 0x2000, &(0x7f0000ffe000/0x2000)=nil}) >> ioctl$KVM_SET_SREGS(r2, 0x4138ae84, &(0x7f00000003c0)={{}, {}, {}, {}, {}, {}, {}, {}, {}, {}, 0x8005001f, 0x0, 0x0, 0x28, 0x0, 0x6500}) >> ioctl$KVM_RUN(r2, 0xae80, 0x0)
