From patchwork Wed Jan 11 18:06:50 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Woodhouse X-Patchwork-Id: 13097076 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97D66C46467 for ; Wed, 11 Jan 2023 18:07:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235089AbjAKSHF (ORCPT ); Wed, 11 Jan 2023 13:07:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233853AbjAKSG7 (ORCPT ); Wed, 11 Jan 2023 13:06:59 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D943419017 for ; Wed, 11 Jan 2023 10:06:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description; bh=sIwFrSB3dAWRGgXHyvaeh8/GR40U/gamS+kA73hvK1o=; b=Ky+aWEKtRaDXl1E1wCUTIFPJSz WxWQ5X69gkSjBMuuxyCD9VtaP0ID1tlk4YG+CJB8CJQ+wmJ6aAjVYB5LOG8H3+dbHUcJ1AnZR7j5M HVQpgGG/FnErHlcuzAscYDG0ENQFVpTLB5aAwTivozhG+XyisZGj46XuTZCeXH3mKX8ueNKpgpWcP NFlCU/SxDILdl/po9tzMPR10N96RavS5vcoHoxSU/Ex2oNLZ2xqel+FOCNEvXFXkno18t4bpr/J/U ihOa5Q+IaMe1olRQZ1qQaT4Z2qYq40Y6iOf6IxEtEhFAEpMhdsnfL5oDNWveN0ds8NdCTmHtcOhTK 59LqEtjg==; Received: from i7.infradead.org ([2001:8b0:10b:1:21e:67ff:fecb:7a92]) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFfVA-004MOu-Vg; Wed, 11 Jan 2023 18:07:05 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFfUx-0003kU-61; Wed, 11 Jan 2023 18:06:51 +0000 From: David Woodhouse To: kvm@vger.kernel.org Cc: Peter Zijlstra , Paolo Bonzini , paul , Sean Christopherson , Michal Luczaj Subject: [PATCH v2 3/4] KVM: Ensure lockdep knows about kvm->lock vs. vcpu->mutex ordering rule Date: Wed, 11 Jan 2023 18:06:50 +0000 Message-Id: <20230111180651.14394-3-dwmw2@infradead.org> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20230111180651.14394-1-dwmw2@infradead.org> References: <20230111180651.14394-1-dwmw2@infradead.org> MIME-Version: 1.0 Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org From: David Woodhouse Documentation/virt/kvm/locking.rst tells us that kvm->lock is taken outside vcpu->mutex. But that doesn't actually happen very often; it's only in some esoteric cases like migration with AMD SEV. This means that lockdep usually doesn't notice, and doesn't do its job of keeping us honest. Ensure that lockdep *always* knows about the ordering of these two locks, by briefly taking vcpu->mutex in kvm_vm_ioctl_create_vcpu() while kvm->lock is held. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- virt/kvm/kvm_main.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 07bf29450521..5814037148bd 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -3924,6 +3924,13 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id) } mutex_lock(&kvm->lock); + +#ifdef CONFIG_LOCKDEP + /* Ensure that lockdep knows vcpu->mutex is taken *inside* kvm->lock */ + mutex_lock(&vcpu->mutex); + mutex_unlock(&vcpu->mutex); +#endif + if (kvm_get_vcpu_by_id(kvm, id)) { r = -EEXIST; goto unlock_vcpu_destroy;