All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/10] KVM: Do not zero initialize 'pfn' in hva_to_pfn()
Date: Thu, 16 Jun 2022 16:51:48 +0000	[thread overview]
Message-ID: <YqtfpKof5IEBdKW4@google.com> (raw)
In-Reply-To: <3dccee6c-8682-66c8-6a22-e58630825443@redhat.com>

On Thu, Jun 16, 2022, Paolo Bonzini wrote:
> On 4/29/22 03:04, Sean Christopherson wrote:
> > Drop the unnecessary initialization of the local 'pfn' variable in
> > hva_to_pfn().  First and foremost, '0' is not an invalid pfn, it's a
> > perfectly valid pfn on most architectures.  I.e. if hva_to_pfn() were to
> > return an "uninitializd" pfn, it would actually be interpeted as a legal
> > pfn by most callers.
> > 
> > Second, hva_to_pfn() can't return an uninitialized pfn as hva_to_pfn()
> > explicitly sets pfn to an error value (or returns an error value directly)
> > if a helper returns failure, and all helpers set the pfn on success.
> > 
> > Note, the zeroing of 'pfn' was introduced by commit 2fc843117d64 ("KVM:
> > reorganize hva_to_pfn"), and was unnecessary and misguided paranoia even
> > then.
> > 
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> >   virt/kvm/kvm_main.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index 0848430f36c6..04ed4334473c 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -2567,7 +2567,7 @@ kvm_pfn_t hva_to_pfn(unsigned long addr, bool atomic, bool *async,
> >   		     bool write_fault, bool *writable)
> >   {
> >   	struct vm_area_struct *vma;
> > -	kvm_pfn_t pfn = 0;
> > +	kvm_pfn_t pfn;
> >   	int npages, r;
> >   	/* we can do it either atomically or asynchronously, not both */
> 
> I wonder if it was needed to avoid uninitialized variable warnings on
> "return pfn;"...

That was my guess too, but IIRC I tried the old code with older compilers (gcc-7)
and couldn't trigger any warning.  So AFAICT, it was pure paranoia.

  reply	other threads:[~2022-06-16 16:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-29  1:04 [PATCH 00/10] KVM: Clean up 'struct page' / pfn helpers Sean Christopherson
2022-04-29  1:04 ` [PATCH 01/10] KVM: Do not zero initialize 'pfn' in hva_to_pfn() Sean Christopherson
2022-06-16 14:54   ` Paolo Bonzini
2022-06-16 16:51     ` Sean Christopherson [this message]
2022-04-29  1:04 ` [PATCH 02/10] KVM: Drop bogus "pfn != 0" guard from kvm_release_pfn() Sean Christopherson
2022-04-29  1:04 ` [PATCH 03/10] KVM: Don't set Accessed/Dirty bits for ZERO_PAGE Sean Christopherson
2022-04-29  1:04 ` [PATCH 04/10] KVM: Avoid pfn_to_page() and vice versa when releasing pages Sean Christopherson
2022-06-16 15:00   ` Paolo Bonzini
2022-06-16 16:54     ` Sean Christopherson
2022-04-29  1:04 ` [PATCH 05/10] KVM: nVMX: Use kvm_vcpu_map() to get/pin vmcs12's APIC-access page Sean Christopherson
2022-04-29  1:04 ` [PATCH 06/10] KVM: Don't WARN if kvm_pfn_to_page() encounters a "reserved" pfn Sean Christopherson
2022-04-29  1:04 ` [PATCH 07/10] KVM: Remove kvm_vcpu_gfn_to_page() and kvm_vcpu_gpa_to_page() Sean Christopherson
2022-04-29  1:04 ` [PATCH 08/10] KVM: Take a 'struct page', not a pfn in kvm_is_zone_device_page() Sean Christopherson
2022-04-29  1:04 ` [PATCH 09/10] KVM: Rename/refactor kvm_is_reserved_pfn() to kvm_pfn_to_refcounted_page() Sean Christopherson
2022-04-29  1:04 ` [PATCH 10/10] KVM: x86/mmu: Shove refcounted page dependency into host_pfn_mapping_level() Sean Christopherson
2022-06-16 15:21 ` [PATCH 00/10] KVM: Clean up 'struct page' / pfn helpers Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YqtfpKof5IEBdKW4@google.com \
    --to=seanjc@google.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.