SRCU dereference check warning with SEV-ES

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Boris noticed the below warning when running an SEV-ES guest with
CONFIG_PROVE_LOCKING=y.

The SRCU lock is released before invoking the vCPU run op where the SEV-ES
support will unmap the GHCB. Is the proper thing to do here to take the
SRCU lock around the call to kvm_vcpu_unmap() in this case? It does fix
the issue, but I just want to be sure that I shouldn't, instead, be taking
the memslot lock:

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 17adc1e79136..76f90cf8c5aa 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2723,7 +2723,10 @@ static void pre_sev_es_run(struct vcpu_svm *svm)
 
 	sev_es_sync_to_ghcb(svm);
 
+	svm->vcpu.srcu_idx = srcu_read_lock(&svm->vcpu.kvm->srcu);
 	kvm_vcpu_unmap(&svm->vcpu, &svm->ghcb_map, true);
+	srcu_read_unlock(&svm->vcpu.kvm->srcu, svm->vcpu.srcu_idx);
+
 	svm->ghcb = NULL;
 }

Thanks,
Tom 

[   97.455047] =============================
[   97.459150] WARNING: suspicious RCU usage
[   97.463259] 5.11.0 #1 Not tainted
[   97.466674] -----------------------------
[   97.470783] include/linux/kvm_host.h:641 suspicious rcu_dereference_check() usage!
[   97.478479] 
               other info that might help us debug this:

[   97.486606] 
               rcu_scheduler_active = 2, debug_locks = 1
[   97.493246] 1 lock held by qemu-system-x86/3793:
[   97.497967]  #0: ffff88810fe800c8 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x6d/0x650 [kvm]
[   97.507059] 
               stack backtrace:
[   97.511515] CPU: 0 PID: 3793 Comm: qemu-system-x86 Not tainted 5.11.0 #1
[   97.518335] Hardware name: GIGABYTE MZ01-CE1-00/MZ01-CE1-00, BIOS F02 08/29/2018
[   97.525849] Call Trace:
[   97.528385]  dump_stack+0x77/0x97
[   97.531832]  kvm_vcpu_gfn_to_memslot+0x168/0x170 [kvm]
[   97.537172]  kvm_vcpu_unmap+0x28/0x60 [kvm]
[   97.541548]  pre_sev_run+0x122/0x250 [kvm_amd]
[   97.546132]  svm_vcpu_run+0x505/0x760 [kvm_amd]
[   97.550806]  kvm_arch_vcpu_ioctl_run+0xe03/0x1c20 [kvm]
[   97.556251]  ? kvm_arch_vcpu_ioctl_run+0xb9/0x1c20 [kvm]
[   97.561780]  ? __lock_acquire+0x38e/0x1c30
[   97.566031]  kvm_vcpu_ioctl+0x222/0x650 [kvm]
[   97.570585]  ? __fget_files+0xe3/0x190
[   97.574459]  ? __fget_files+0x5/0x190
[   97.578254]  __x64_sys_ioctl+0x98/0xd0
[   97.582130]  ? lockdep_hardirqs_on+0x88/0x120
[   97.586625]  do_syscall_64+0x34/0x50
[   97.590331]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   97.595521] RIP: 0033:0x7f728ffeb457
[   97.599222] Code: 00 00 90 48 8b 05 39 7a 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 7a 0c 00 f7 d8 64 89 01 48
[   97.618277] RSP: 002b:00007f7287ffe7e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[   97.626029] RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00007f728ffeb457
[   97.633315] RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000015
[   97.640595] RBP: 000055d927433480 R08: 000055d924adb278 R09: 00000000ffffffff
[   97.647877] R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000
[   97.655156] R13: 00007f7290939004 R14: 0000000000000cf8 R15: 0000000000000000



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux