[PATCH] KVM: fix memoryleak in kvm_init()

[PATCH] KVM: fix memoryleak in kvm_init()

[Miaohe Lin]

When alloc_cpumask_var_node() fails for a certain cpu, there might be some
allocated cpumasks for percpu cpu_kick_mask. We should free these cpumasks
or memoryleak will occur.

Fixes: baff59ccdc65 ("KVM: Pre-allocate cpumasks for kvm_make_all_cpus_request_except()")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
---
 virt/kvm/kvm_main.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 584a5bab3af3..dcf47da44844 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -5881,7 +5881,7 @@ int kvm_init(void *opaque, unsigned vcpu_size, unsigned vcpu_align,
 
 	r = kvm_async_pf_init();
 	if (r)
-		goto out_free_5;
+		goto out_free_4;
 
 	kvm_chardev_ops.owner = module;
 
@@ -5905,10 +5905,9 @@ int kvm_init(void *opaque, unsigned vcpu_size, unsigned vcpu_align,
 
 out_unreg:
 	kvm_async_pf_deinit();
-out_free_5:
+out_free_4:
 	for_each_possible_cpu(cpu)
 		free_cpumask_var(per_cpu(cpu_kick_mask, cpu));
-out_free_4:
 	kmem_cache_destroy(kvm_vcpu_cache);
 out_free_3:
 	unregister_reboot_notifier(&kvm_reboot_notifier);
-- 
2.23.0

Re: [PATCH] KVM: fix memoryleak in kvm_init()

[Sean Christopherson]

On Tue, Aug 23, 2022, Miaohe Lin wrote:
> When alloc_cpumask_var_node() fails for a certain cpu, there might be some
> allocated cpumasks for percpu cpu_kick_mask. We should free these cpumasks
> or memoryleak will occur.
> 
> Fixes: baff59ccdc65 ("KVM: Pre-allocate cpumasks for kvm_make_all_cpus_request_except()")
> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> ---

Reviewed-by: Sean Christopherson <seanjc@google.com>

Re: [PATCH] KVM: fix memoryleak in kvm_init()

[Sean Christopherson]

On Tue, Aug 23, 2022, Miaohe Lin wrote:
> When alloc_cpumask_var_node() fails for a certain cpu, there might be some
> allocated cpumasks for percpu cpu_kick_mask. We should free these cpumasks
> or memoryleak will occur.
> 
> Fixes: baff59ccdc65 ("KVM: Pre-allocate cpumasks for kvm_make_all_cpus_request_except()")
> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> ---

Pushed to branch `for_paolo/6.1` at:

    https://github.com/sean-jc/linux.git

Unless you hear otherwise, it will make its way to kvm/queue "soon".

Note, the commit IDs are not guaranteed to be stable.

Re: [PATCH] KVM: fix memoryleak in kvm_init()

[Paolo Bonzini]

On 8/30/22 23:36, Sean Christopherson wrote:
> On Tue, Aug 23, 2022, Miaohe Lin wrote:
>> When alloc_cpumask_var_node() fails for a certain cpu, there might be some
>> allocated cpumasks for percpu cpu_kick_mask. We should free these cpumasks
>> or memoryleak will occur.
>>
>> Fixes: baff59ccdc65 ("KVM: Pre-allocate cpumasks for kvm_make_all_cpus_request_except()")
>> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
>> ---
> 
> Pushed to branch `for_paolo/6.1` at:
> 
>      https://github.com/sean-jc/linux.git
> 
> Unless you hear otherwise, it will make its way to kvm/queue "soon".
> 
> Note, the commit IDs are not guaranteed to be stable.

Hmm, I was going to merge these memory leak fixes for 6.0, but no big 
deal since they're mostly theoretical anyway.

Paolo

Re: [PATCH] KVM: fix memoryleak in kvm_init()

[Sean Christopherson]

On Fri, Sep 02, 2022, Paolo Bonzini wrote:
> On 8/30/22 23:36, Sean Christopherson wrote:
> > On Tue, Aug 23, 2022, Miaohe Lin wrote:
> > > When alloc_cpumask_var_node() fails for a certain cpu, there might be some
> > > allocated cpumasks for percpu cpu_kick_mask. We should free these cpumasks
> > > or memoryleak will occur.
> > > 
> > > Fixes: baff59ccdc65 ("KVM: Pre-allocate cpumasks for kvm_make_all_cpus_request_except()")
> > > Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> > > ---
> > 
> > Pushed to branch `for_paolo/6.1` at:
> > 
> >      https://github.com/sean-jc/linux.git
> > 
> > Unless you hear otherwise, it will make its way to kvm/queue "soon".
> > 
> > Note, the commit IDs are not guaranteed to be stable.
> 
> Hmm, I was going to merge these memory leak fixes for 6.0, but no big deal
> since they're mostly theoretical anyway.

Take them, I wasn't sure and was anticipating possibly dropping them anyways.  I
can easily adjust, and was deliberately a little greedy for these technically-a-bug
memory leaks so that we would't miss them by thinking the other would grab 'em.