Received: by 2002:a05:6a10:83d0:0:0:0:0 with SMTP id o16csp87334pxh; Thu, 7 Apr 2022 14:52:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzAk4gIJ4BtEQc0wIZ6BHTkYelRjuHmzLKYfe6VgwqojMWQNVaBxDA/3MSXbvQ5OlSCuYEa X-Received: by 2002:a05:6a00:cc5:b0:4fb:4969:3eb with SMTP id b5-20020a056a000cc500b004fb496903ebmr16158483pfv.59.1649368372559; Thu, 07 Apr 2022 14:52:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649368372; cv=none; d=google.com; s=arc-20160816; b=lrsxcdFiRVzE9B5C9dJCz3SZkfyFfN0Dw+JlTTWM/5Xa5ClC2Wlgn+GH+frrnx0GgF krNf3QnjPV/CzQBVj7gUpB+7RxWJ9OdzVZLtwws9xnRy1An7M/fYNjQxfaHNtUfK1gqd QFE66w8tVFpCCxDTI2IzGzSA+xM/mICFiUZZtr6KOqSPD16R9cQ5UstYkSroUz+wQeo3 mzY93qUF46WSVObu8hwwRLjTOgzbJA7VrjXKrUc2P+/H9WBr3LFtY5IIqQXXtS6GWzM6 AyoPmhmuxPzouTPNx37nGrzXdd8aOTGN4oD/HKFLappjR0CNiIyIOgCXC9MHvLGoi/px hDqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=i2UZnvHKVT+RSn7KzBoROaF7ppe0N+yUXrxxXIoW5cQ=; b=TbqSXNmCtgl/Xh6Uiq/UqGvHB2BWtwVTQBLUeO7A4rs9IQp2kTBbC9ERBRsHDlGGU6 /pLFgHoij22YLghtlWb2LKgPSW1hePgdNNd7JDHpfSVB8FQPkJ0d+NUQ3To/vl9GrnlE IdhzmdM5v6qaL/soQF0EvYQYK2ASYkN9ncVuDnihRzlCBSeN9hcX7SoYq6rhHWAvLr7U dC9gLvMexMZZ0/6Gzrb/sGBIjilo3015ECOCNfmthN8iMiCwZ3osTre8ZKwpcbe83DEt Eh7fH1Jt/DbNnpHBysM1V+v6M5nYF9xFUyYF/k/Pz1RtAOUVe/T/hU0dByyPfRHBdVzk JDmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=NRde8Udp; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id i62-20020a628741000000b004fa3a8dffefsi18899062pfe.166.2022.04.07.14.52.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 14:52:52 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=NRde8Udp; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E09AD18CD1D; Thu, 7 Apr 2022 14:17:55 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231301AbiDGVTu (ORCPT + 99 others); Thu, 7 Apr 2022 17:19:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231226AbiDGVTp (ORCPT ); Thu, 7 Apr 2022 17:19:45 -0400 Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4A2E18B27D for ; Thu, 7 Apr 2022 14:17:44 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id a20so3876082uaq.11 for ; Thu, 07 Apr 2022 14:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i2UZnvHKVT+RSn7KzBoROaF7ppe0N+yUXrxxXIoW5cQ=; b=NRde8Udpa0fzUmYWUGIa2y+TMLicphp0YP1FxdyLiInbSRONN31LTYfw9J+ZkQIrVr SaP9jmOZseRLuHjTaS8/+DI7H9Y/PwQtd83V3kvjKqKCV7u6elpRVIWo7nB+bjA1tgnv hf56DvjcJNWLJHDl6c/8Nnn7rs6WvkEFHalj4Tmcmq9uvv3NGkq3zZfoFE2cS97uk7hM Le1N5tuX81k2d+QfJcsxcSRcJWaI7WjzU1qtGIQZswIkXMPtnNfr5Xk3VnmM5o5OwkTY QRAtpAD497ANr6wxriL34hQkjTfbKK/p5EEzzGEsoi2VTY2VvrVlsFggZsl48g0GLU7C LZ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i2UZnvHKVT+RSn7KzBoROaF7ppe0N+yUXrxxXIoW5cQ=; b=0eb4RZ3gWNG8qtw/ZXI3UL5My1viQwbsiUEEm2lIhoajLTNF1G4faQ/1UlWkDkKF79 wrpdQ4LINtFQ5/wwAvKFluS19C7PtPwGlTHGCw5lSCdCj2w0a4ulHOfWRybVgmNGR9fj euu8p9Zmd1EnDoPb8mlWnycUmDEbVdro9MdnVMTjRPMJIjAJxmZmlJHJnxrPITfcj1oq Mkp9Y2o5GCJNAoLbzq4H5cwmU0J8mLmVQqgduCW6+UfcOuJU3pHwdz8/TnZE5QfyOLjB Yb/gAxfPFXYEcV21Ay7Chq8dzeplTpJh6lQmHJOICcLHay1NPT1FjmMLl8hAsszl/koO qjKg== X-Gm-Message-State: AOAM531wB01hUTwbX5qequT76tOGncaygNssD7E/UHaZNoo3fLHs5n+E iF8szXe2SH+pphm/GgOf5YTlJLZD6PD1KqGFpcwMNQ== X-Received: by 2002:ab0:7541:0:b0:359:eb0b:8162 with SMTP id k1-20020ab07541000000b00359eb0b8162mr4673151uaq.15.1649366263664; Thu, 07 Apr 2022 14:17:43 -0700 (PDT) MIME-Version: 1.0 References: <20220407195908.633003-1-pgonda@google.com> In-Reply-To: <20220407195908.633003-1-pgonda@google.com> From: John Sperbeck Date: Thu, 7 Apr 2022 14:17:32 -0700 Message-ID: Subject: Re: [PATCH v3] KVM: SEV: Mark nested locking of vcpu->lock To: Peter Gonda Cc: kvm@vger.kernel.org, David Rientjes , Sean Christopherson , Paolo Bonzini , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 7, 2022 at 12:59 PM Peter Gonda wrote: > > svm_vm_migrate_from() uses sev_lock_vcpus_for_migration() to lock all > source and target vcpu->locks. Mark the nested subclasses to avoid false > positives from lockdep. > > Warning example: > ============================================ > WARNING: possible recursive locking detected > 5.17.0-dbg-DEV #15 Tainted: G O > -------------------------------------------- > sev_migrate_tes/18859 is trying to acquire lock: > ffff8d672d484238 (&vcpu->mutex){+.+.}-{3:3}, at: sev_lock_vcpus_for_migration+0x7e/0x150 > but task is already holding lock: > ffff8d67703f81f8 (&vcpu->mutex){+.+.}-{3:3}, at: sev_lock_vcpus_for_migration+0x7e/0x150 > other info that might help us debug this: > Possible unsafe locking scenario: > CPU0 > ---- > lock(&vcpu->mutex); > lock(&vcpu->mutex); > *** DEADLOCK *** > May be due to missing lock nesting notation > 3 locks held by sev_migrate_tes/18859: > #0: ffff9302f91323b8 (&kvm->lock){+.+.}-{3:3}, at: sev_vm_move_enc_context_from+0x96/0x740 > #1: ffff9302f906a3b8 (&kvm->lock/1){+.+.}-{3:3}, at: sev_vm_move_enc_context_from+0xae/0x740 > #2: ffff8d67703f81f8 (&vcpu->mutex){+.+.}-{3:3}, at: sev_lock_vcpus_for_migration+0x7e/0x150 > > Fixes: b56639318bb2b ("KVM: SEV: Add support for SEV intra host migration") > Reported-by: John Sperbeck > Suggested-by: David Rientjes > Suggested-by: Sean Christopherson > Cc: Paolo Bonzini > Cc: kvm@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Peter Gonda > > --- > > V3 > * Updated signature to enum to self-document argument. > * Updated comment as Seanjc@ suggested. > > Tested by running sev_migrate_tests with lockdep enabled. Before we see > a warning from sev_lock_vcpus_for_migration(). After we get no warnings. > > --- > arch/x86/kvm/svm/sev.c | 22 +++++++++++++++++----- > 1 file changed, 17 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > index 75fa6dd268f0..f66550ec8eaf 100644 > --- a/arch/x86/kvm/svm/sev.c > +++ b/arch/x86/kvm/svm/sev.c > @@ -1591,14 +1591,26 @@ static void sev_unlock_two_vms(struct kvm *dst_kvm, struct kvm *src_kvm) > atomic_set_release(&src_sev->migration_in_progress, 0); > } > > +/* > + * To suppress lockdep false positives, subclass all vCPU mutex locks by > + * assigning even numbers to the source vCPUs and odd numbers to destination > + * vCPUs based on the vCPU's index. > + */ > +enum sev_migration_role { > + SEV_MIGRATION_SOURCE = 0, > + SEV_MIGRATION_TARGET, > + SEV_NR_MIGRATION_ROLES, > +}; > > -static int sev_lock_vcpus_for_migration(struct kvm *kvm) > +static int sev_lock_vcpus_for_migration(struct kvm *kvm, > + enum sev_migration_role role) > { > struct kvm_vcpu *vcpu; > unsigned long i, j; > > - kvm_for_each_vcpu(i, vcpu, kvm) { > - if (mutex_lock_killable(&vcpu->mutex)) > + kvm_for_each_vcpu(i, vcpu, kvm) { > + if (mutex_lock_killable_nested( > + &vcpu->mutex, i * SEV_NR_MIGRATION_ROLES + role)) > goto out_unlock; > } > > @@ -1745,10 +1757,10 @@ int sev_vm_move_enc_context_from(struct kvm *kvm, unsigned int source_fd) > charged = true; > } > > - ret = sev_lock_vcpus_for_migration(kvm); > + ret = sev_lock_vcpus_for_migration(kvm, SEV_MIGRATION_SOURCE); > if (ret) > goto out_dst_cgroup; > - ret = sev_lock_vcpus_for_migration(source_kvm); > + ret = sev_lock_vcpus_for_migration(source_kvm, SEV_MIGRATION_TARGET); > if (ret) > goto out_dst_vcpu; > > -- > 2.35.1.1178.g4f1659d476-goog > Does sev_migrate_tests survive lockdep checking if NR_MIGRATE_TEST_VCPUS is changed to 16?