Commit 23e60258 authored by David Woodhouse's avatar David Woodhouse Committed by Paolo Bonzini
Browse files

KVM: x86/xen: Fix lockdep warning on "recursive" gpc locking 



In commit 5ec3289b ("KVM: x86/xen: Compatibility fixes for shared runstate
area") we declared it safe to obtain two gfn_to_pfn_cache locks at the same
time:
	/*
	 * The guest's runstate_info is split across two pages and we
	 * need to hold and validate both GPCs simultaneously. We can
	 * declare a lock ordering GPC1 > GPC2 because nothing else
	 * takes them more than one at a time.
	 */

However, we forgot to tell lockdep. Do so, by setting a subclass on the
first lock before taking the second.

Fixes: 5ec3289b ("KVM: x86/xen: Compatibility fixes for shared runstate area")
Suggested-by: default avatarPeter Zijlstra <peterz@infradead.org>
Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
Message-Id: <20230111180651.14394-1-dwmw2@infradead.org>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
parent 71d03935

arch/x86/kvm/xen.c

+3 −1
Original line number Diff line number Diff line
@@ -304,8 +304,10 @@ static void kvm_xen_update_runstate_guest(struct kvm_vcpu *v, bool atomic) 
		 * The guest's runstate_info is split across two pages and we

		 * need to hold and validate both GPCs simultaneously. We can

		 * declare a lock ordering GPC1 > GPC2 because nothing else

		 * takes them more than one at a time.

		 * takes them more than one at a time. Set a subclass on the

		 * gpc1 lock to make lockdep shut up about it.

		 */

		lock_set_subclass(&gpc1->lock.dep_map, 1, _THIS_IP_);

		read_lock(&gpc2->lock);



		if (!kvm_gpc_check(gpc2, user_len2)) {