From: Sean Christopherson <seanjc@google.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>,
Maxim Levitsky <mlevitsk@redhat.com>,
coverity-bot <keescook@chromium.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: hyper-v: Fix 'using uninitialized value' Coverity warning
Date: Fri, 2 Dec 2022 15:44:04 +0000 [thread overview]
Message-ID: <Y4odRLlFRj17tUNE@google.com> (raw)
In-Reply-To: <20221202105856.434886-1-vkuznets@redhat.com>
On Fri, Dec 02, 2022, Vitaly Kuznetsov wrote:
> In kvm_hv_flush_tlb(), 'data_offset' and 'consumed_xmm_halves' variables
> are used in a mutually exclusive way: in 'hc->fast' we count in 'XMM
> halves' and increase 'data_offset' otherwise. Coverity discovered, that in
> one case both variables are incremented unconditionally. This doesn't seem
> to cause any issues as the only user of 'data_offset'/'consumed_xmm_halves'
> data is kvm_hv_get_tlb_flush_entries() -> kvm_hv_get_hc_data() which also
> takes into account 'hc->fast' but is still worth fixing.
If those calls aren't inlined, then 32-bit Hyper-V will be "consuming" uninitialized
data when pushing parameters onto the stack. It won't cause real problems, but
checkers might complain.
What about shoving this metadata into "struct kvm_hv_hcall" as a union? That'd
help convey that the two are mutually exclusive, would provide a place to document
said exclusion, and would yield a nice cleanup too by eliminating multiple params
from various functions.
next prev parent reply other threads:[~2022-12-02 15:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-02 10:58 [PATCH] KVM: x86: hyper-v: Fix 'using uninitialized value' Coverity warning Vitaly Kuznetsov
2022-12-02 15:44 ` Sean Christopherson [this message]
2022-12-06 13:53 ` Vitaly Kuznetsov
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=Y4odRLlFRj17tUNE@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=keescook@chromium.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--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.