linux-kernel - Re: [PATCH MANUALSEL 5.15 4/9] KVM: SEV: do not take kvm->lock when destroying

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c7d9016a-8129-0568-a640-cbbca18867bb@redhat.com>
Date:   Mon, 13 Dec 2021 15:27:41 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Sasha Levin <sashal@...nel.org>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Cc:     Sean Christopherson <seanjc@...gle.com>, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
        x86@...nel.org, kvm@...r.kernel.org
Subject: Re: [PATCH MANUALSEL 5.15 4/9] KVM: SEV: do not take kvm->lock when
 destroying

On 12/13/21 15:19, Sasha Levin wrote:
> From: Paolo Bonzini <pbonzini@...hat.com>
> 
> [ Upstream commit 10a37929efeb4c51a0069afdd537c4fa3831f6e5 ]
> 
> Taking the lock is useless since there are no other references,
> and there are already accesses (e.g. to sev->enc_context_owner)
> that do not take it.  So get rid of it.
> 
> Reviewed-by: Sean Christopherson <seanjc@...gle.com>
> Message-Id: <20211123005036.2954379-12-pbonzini@...hat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
> Signed-off-by: Sasha Levin <sashal@...nel.org>
> ---
>   arch/x86/kvm/svm/sev.c | 4 ----
>   1 file changed, 4 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 134c4ea5e6ad8..ae8092f0d401e 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -1842,8 +1842,6 @@ void sev_vm_destroy(struct kvm *kvm)
>   		return;
>   	}
>   
> -	mutex_lock(&kvm->lock);
> -
>   	/*
>   	 * Ensure that all guest tagged cache entries are flushed before
>   	 * releasing the pages back to the system for use. CLFLUSH will
> @@ -1863,8 +1861,6 @@ void sev_vm_destroy(struct kvm *kvm)
>   		}
>   	}
>   
> -	mutex_unlock(&kvm->lock);
> -
>   	sev_unbind_asid(kvm, sev->handle);
>   	sev_asid_free(sev);
>   }
> 

This is cosmetic only, so

NACK

Paolo