From: Junaid Shahid <junaids@google.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>,
Jim Mattson <jmattson@google.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
John Sperbeck <jsperbeck@google.com>
Subject: Re: [PATCH] kvm: call kvm_arch_destroy_vm if vm creation fails
Date: Wed, 23 Oct 2019 19:59:45 -0700 [thread overview]
Message-ID: <7e1fe902-65e3-5381-1ac8-b280f39a677d@google.com> (raw)
In-Reply-To: <20191023182106.GB26295@linux.intel.com>
On 10/23/19 11:21 AM, Sean Christopherson wrote:
>> out_err_no_disable:
>> refcount_set(&kvm->users_count, 0);
>> + kvm_arch_destroy_vm(kvm);
>
> Calling destroy_vm() after zeroing the refcount could lead to a refcount
> underrun (and a WARN with CONFIG_REFCOUNT_FULL=y) if an arch were to do
> kvm_put_kvm() in destroy_vm() to pair with a kvm_get_kvm() in create_vm().
> I doubt any arch actually does that, but it's technically possible since
> kvm_arch_create_vm() is called with users_count=1.
>
> If we wanted to be paranoid, a follow-up patch could change refcount_set()
> to WARN_ON(!refcount_dec_and_dest()), e.g.:
>
> kvm_arch_destroy_vm(kvm);
> WARN_ON(!refcount_dec_and_dest(&kvm->users_count));
>
AFAICT the kvm->users_count is already 0 before kvm_arch_destroy_vm() is called from kvm_destroy_vm() in the normal case. So there really shouldn't be any arch that does a kvm_put_kvm() inside kvm_arch_destroy_vm(). I think it might be better to keep the kvm_arch_destroy_vm() call after the refcount_set() to be consistent with the normal path.
next prev parent reply other threads:[~2019-10-24 2:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 17:14 [PATCH] kvm: call kvm_arch_destroy_vm if vm creation fails Jim Mattson
2019-10-23 18:21 ` Sean Christopherson
2019-10-24 2:59 ` Junaid Shahid [this message]
2019-10-24 10:08 ` Paolo Bonzini
2019-10-24 18:14 ` Sean Christopherson
2019-10-24 18:55 ` 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=7e1fe902-65e3-5381-1ac8-b280f39a677d@google.com \
--to=junaids@google.com \
--cc=jmattson@google.com \
--cc=jsperbeck@google.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox