On Tue, 2023-01-10 at 19:37 +0000, Sean Christopherson wrote:
> No idea about the splat below, but kvm_vcpu_init() doesn't run under kvm->lock,
> so I wouldn't expect this to do anything.
Ah, good point. I think I misread kvm_vm_ioctl_create_vcpu() *dropping*
kvm->lock a few lines above calling kvm_vcpu_init().
This one gives me the splat I was *expecting*. But Paolo said he had a
patch for that and now the other one is *much* more interesting...
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3924,6 +3924,11 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id)
}
mutex_lock(&kvm->lock);
+
+ /* Ensure that lockdep knows vcpu->mutex is taken *inside* kvm->lock */
+ mutex_lock(&vcpu->mutex);
+ mutex_unlock(&vcpu->mutex);
+
if (kvm_get_vcpu_by_id(kvm, id)) {
r = -EEXIST;
goto unlock_vcpu_destroy;
[ 111.042398] ======================================================
[ 111.042400] WARNING: possible circular locking dependency detected
[ 111.042402] 6.1.0-rc4+ #1024 Tainted: G I E
[ 111.042405] ------------------------------------------------------
[ 111.042406] xen_shinfo_test/11035 is trying to acquire lock:
[ 111.042409] ffffc900017803c0 (&kvm->lock){+.+.}-{3:3}, at: kvm_xen_vcpu_set_attr+0x2a/0x4f0 [kvm]
[ 111.042494]
but task is already holding lock:
[ 111.042496] ffff88828f9600b0 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x77/0x700 [kvm]
[ 111.042547]
which lock already depends on the new lock.
[ 111.042548]
the existing dependency chain (in reverse order) is:
[ 111.042550]
-> #1 (&vcpu->mutex){+.+.}-{3:3}:
[ 111.042554] __lock_acquire+0x4b4/0x940
[ 111.042561] lock_acquire.part.0+0xa8/0x210
[ 111.042564] __mutex_lock+0x94/0x920
[ 111.042571] kvm_vm_ioctl_create_vcpu+0x1c1/0x4b0 [kvm]
[ 111.042618] kvm_vm_ioctl+0x565/0x7f0 [kvm]
[ 111.042664] __x64_sys_ioctl+0x8a/0xc0
[ 111.042669] do_syscall_64+0x3b/0x90
[ 111.042674] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 111.042679]
-> #0 (&kvm->lock){+.+.}-{3:3}:
[ 111.042683] check_prev_add+0x8f/0xc20
[ 111.042687] validate_chain+0x3ba/0x450
[ 111.042690] __lock_acquire+0x4b4/0x940
[ 111.042693] lock_acquire.part.0+0xa8/0x210
[ 111.042696] __mutex_lock+0x94/0x920
[ 111.042700] kvm_xen_vcpu_set_attr+0x2a/0x4f0 [kvm]
[ 111.042764] kvm_arch_vcpu_ioctl+0x817/0x12a0 [kvm]
[ 111.042817] kvm_vcpu_ioctl+0x519/0x700 [kvm]
[ 111.042862] __x64_sys_ioctl+0x8a/0xc0
[ 111.042865] do_syscall_64+0x3b/0x90
[ 111.042869] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 111.042873]
other info that might help us debug this:
[ 111.042875] Possible unsafe locking scenario:
[ 111.042876] CPU0 CPU1
[ 111.042878] ---- ----
[ 111.042879] lock(&vcpu->mutex);
[ 111.042882] lock(&kvm->lock);
[ 111.042884] lock(&vcpu->mutex);
[ 111.042887] lock(&kvm->lock);
[ 111.042889]
*** DEADLOCK ***
[ 111.042891] 1 lock held by xen_shinfo_test/11035:
[ 111.042893] #0: ffff88828f9600b0 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x77/0x700 [kvm]
[ 111.042943]
stack backtrace:
[ 111.042946] CPU: 23 PID: 11035 Comm: xen_shinfo_test Tainted: G I E 6.1.0-rc4+ #1024
[ 111.042949] Hardware name: Intel Corporation S2600CW/S2600CW, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015
[ 111.042952] Call Trace:
[ 111.042954] <TASK>
[ 111.042957] dump_stack_lvl+0x56/0x73
[ 111.042963] check_noncircular+0x102/0x120
[ 111.042970] check_prev_add+0x8f/0xc20
[ 111.042973] ? add_chain_cache+0x10b/0x2d0
[ 111.042976] ? _raw_spin_unlock_irqrestore+0x2d/0x60
[ 111.042982] validate_chain+0x3ba/0x450
[ 111.042986] __lock_acquire+0x4b4/0x940
[ 111.042991] lock_acquire.part.0+0xa8/0x210
[ 111.042995] ? kvm_xen_vcpu_set_attr+0x2a/0x4f0 [kvm]
[ 111.043061] ? rcu_read_lock_sched_held+0x43/0x70
[ 111.043067] ? lock_acquire+0x102/0x140
[ 111.043072] __mutex_lock+0x94/0x920
[ 111.043077] ? kvm_xen_vcpu_set_attr+0x2a/0x4f0 [kvm]
[ 111.043141] ? __lock_acquire+0x4b4/0x940
[ 111.043145] ? kvm_xen_vcpu_set_attr+0x2a/0x4f0 [kvm]
[ 111.043209] ? kvm_xen_vcpu_set_attr+0x2a/0x4f0 [kvm]
[ 111.043271] ? vmx_vcpu_load+0x27/0x40 [kvm_intel]
[ 111.043286] kvm_xen_vcpu_set_attr+0x2a/0x4f0 [kvm]
[ 111.043349] ? kvm_arch_vcpu_load+0x66/0x200 [kvm]
[ 111.043405] kvm_arch_vcpu_ioctl+0x817/0x12a0 [kvm]
[ 111.043464] ? trace_contention_end+0x2d/0xd0
[ 111.043475] kvm_vcpu_ioctl+0x519/0x700 [kvm]
[ 111.043525] ? do_user_addr_fault+0x1fa/0x6b0
[ 111.043532] ? do_user_addr_fault+0x1fa/0x6b0
[ 111.043538] __x64_sys_ioctl+0x8a/0xc0
[ 111.043544] do_syscall_64+0x3b/0x90
[ 111.043549] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 111.043554] RIP: 0033:0x7f485cc3fd1b
[ 111.043558] Code: 73 01 c3 48 8b 0d 05 a1 1b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d d5 a0 1b 00 f7 d8 64 89 01 48
[ 111.043561] RSP: 002b:00007ffe8726c018 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 111.043565] RAX: ffffffffffffffda RBX: 00007f485d027000 RCX: 00007f485cc3fd1b
[ 111.043568] RDX: 00007ffe8726c160 RSI: 000000004048aecb RDI: 0000000000000007
[ 111.043570] RBP: 00007f485cff26c0 R08: 00000000004188f0 R09: 0000000000000000
[ 111.043573] R10: 0000000000000012 R11: 0000000000000246 R12: 0000000000000010
[ 111.043575] R13: 000000002645a922 R14: 63bdc02500000002 R15: 00000000021082a0
[ 111.043581] </TASK>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
