From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jim Mattson <jmattson@google.com>,
kvm@vger.kernel.org, John Sperbeck <jsperbeck@google.com>,
Junaid Shahid <junaids@google.com>
Subject: Re: [PATCH v3 3/3] kvm: call kvm_arch_destroy_vm if vm creation fails
Date: Fri, 25 Oct 2019 08:22:01 -0700 [thread overview]
Message-ID: <20191025152201.GD17290@linux.intel.com> (raw)
In-Reply-To: <7fa85679-7325-4373-55a1-bb2cd274fec3@redhat.com>
On Fri, Oct 25, 2019 at 04:56:23PM +0200, Paolo Bonzini wrote:
> On 25/10/19 16:48, Sean Christopherson wrote:
> >> It seems to me that kvm_get_kvm() in
> >> kvm_arch_init_vm() should be okay as long as it is balanced in
> >> kvm_arch_destroy_vm(). So we can apply patch 2 first, and then:
> > No, this will effectively leak the VM because you'll end up with a cyclical
> > reference to kvm_put_kvm(), i.e. users_count will never hit zero.
> >
> > void kvm_put_kvm(struct kvm *kvm)
> > {
> > if (refcount_dec_and_test(&kvm->users_count))
> > kvm_destroy_vm(kvm);
> > |
> > -> kvm_arch_destroy_vm()
> > |
> > -> kvm_put_kvm()
> > }
>
> There's two parts to this:
>
> - if kvm_arch_init_vm() calls kvm_get_kvm(), then kvm_arch_destroy_vm()
> won't be called until the corresponding kvm_put_kvm().
>
> - if the error case causes kvm_arch_destroy_vm() to be called early,
> however, that'd be okay and would not leak memory, as long as
> kvm_arch_destroy_vm() detects the situation and calls kvm_put_kvm() itself.
>
> One case could be where you have some kind of delayed work, where the
> callback does kvm_put_kvm. You'd have to cancel the work item and call
> kvm_put_kvm in kvm_arch_destroy_vm, and you would go through that path
> if kvm_create_vm() fails after kvm_arch_init_vm().
But do we really want/need to allow handing out references to KVM during
kvm_arch_init_vm()? AFAICT, it's not currently required by any arch.
If an actual use case comes along then we can move refcount_set() back,
but with the requirement that the arch/user provide a mechanism to
handle the reference with respect to kvm_arch_destroy_vm(). As opposed
to the current behavior, which allows an arch to naively do get()/put()
in init_vm()/destroy_vm() without any hint that what they're doing is
broken.
next prev parent reply other threads:[~2019-10-25 15:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 23:03 [PATCH v3 0/3] kvm: call kvm_arch_destroy_vm if vm creation fails Jim Mattson
2019-10-24 23:03 ` [PATCH v3 1/3] kvm: Don't clear reference count on kvm_create_vm() error path Jim Mattson
2019-10-24 23:15 ` Sean Christopherson
2019-10-24 23:03 ` [PATCH v3 2/3] kvm: Allocate memslots and buses before calling kvm_arch_init_vm Jim Mattson
2019-10-24 23:28 ` Sean Christopherson
2019-10-25 11:30 ` Paolo Bonzini
2019-10-24 23:03 ` [PATCH v3 3/3] kvm: call kvm_arch_destroy_vm if vm creation fails Jim Mattson
2019-10-24 23:29 ` Sean Christopherson
2019-10-25 11:37 ` Paolo Bonzini
2019-10-25 14:48 ` Sean Christopherson
2019-10-25 14:56 ` Paolo Bonzini
2019-10-25 15:22 ` Sean Christopherson [this message]
2019-10-25 15:23 ` Paolo Bonzini
2019-10-25 22:29 ` Sean Christopherson
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=20191025152201.GD17290@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=jmattson@google.com \
--cc=jsperbeck@google.com \
--cc=junaids@google.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.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.