2021-07-22 06:29:09

by Fei Li

[permalink] [raw]
Subject: [PATCH] virt: acrn: Do hcall_destroy_vm() before resource release

From: Shuo Liu <[email protected]>

The ACRN hypervisor has scenarios which could run a real-time guest VM.
The real-time guest VM occupies dedicated CPU cores, be assigned with
dedicated PCI devices. It can run without the Service VM after boot up.
hcall_destroy_vm() returns failure when a real-time guest VM refuses.
The clearing of flag ACRN_VM_FLAG_DESTROYED causes some kernel resource
double-freed in a later acrn_vm_destroy().

Do hcall_destroy_vm() before resource release to drop this chance to
destroy the VM if hypercall fails.

Fixes: 9c5137aedd11 ("virt: acrn: Introduce VM management interfaces")
Signed-off-by: Shuo Liu <[email protected]>
Signed-off-by: Fei Li <[email protected]>
---
drivers/virt/acrn/vm.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/virt/acrn/vm.c b/drivers/virt/acrn/vm.c
index 0d002a355a93..fbc9f1042000 100644
--- a/drivers/virt/acrn/vm.c
+++ b/drivers/virt/acrn/vm.c
@@ -64,6 +64,14 @@ int acrn_vm_destroy(struct acrn_vm *vm)
test_and_set_bit(ACRN_VM_FLAG_DESTROYED, &vm->flags))
return 0;

+ ret = hcall_destroy_vm(vm->vmid);
+ if (ret < 0) {
+ dev_err(acrn_dev.this_device,
+ "Failed to destroy VM %u\n", vm->vmid);
+ clear_bit(ACRN_VM_FLAG_DESTROYED, &vm->flags);
+ return ret;
+ }
+
/* Remove from global VM list */
write_lock_bh(&acrn_vm_list_lock);
list_del_init(&vm->list);
@@ -78,14 +86,6 @@ int acrn_vm_destroy(struct acrn_vm *vm)
vm->monitor_page = NULL;
}

- ret = hcall_destroy_vm(vm->vmid);
- if (ret < 0) {
- dev_err(acrn_dev.this_device,
- "Failed to destroy VM %u\n", vm->vmid);
- clear_bit(ACRN_VM_FLAG_DESTROYED, &vm->flags);
- return ret;
- }
-
acrn_vm_all_ram_unmap(vm);

dev_dbg(acrn_dev.this_device, "VM %u destroyed.\n", vm->vmid);

base-commit: c453db6cd96418c79702eaf38259002755ab23ff
--
2.17.1


2021-07-27 14:53:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH] virt: acrn: Do hcall_destroy_vm() before resource release

On Thu, Jul 22, 2021 at 02:27:36PM +0800, Fei Li wrote:
> From: Shuo Liu <[email protected]>
>
> The ACRN hypervisor has scenarios which could run a real-time guest VM.
> The real-time guest VM occupies dedicated CPU cores, be assigned with
> dedicated PCI devices. It can run without the Service VM after boot up.
> hcall_destroy_vm() returns failure when a real-time guest VM refuses.
> The clearing of flag ACRN_VM_FLAG_DESTROYED causes some kernel resource
> double-freed in a later acrn_vm_destroy().
>
> Do hcall_destroy_vm() before resource release to drop this chance to
> destroy the VM if hypercall fails.
>
> Fixes: 9c5137aedd11 ("virt: acrn: Introduce VM management interfaces")
> Signed-off-by: Shuo Liu <[email protected]>
> Signed-off-by: Fei Li <[email protected]>
> ---

Do you also want this backported to older kernels? If so, you need to
put a cc: stable in here, right? I'll go add it myself, but be more
careful next time please.

greg k-h

2021-07-29 03:25:13

by Fei Li

[permalink] [raw]
Subject: Re: [PATCH] virt: acrn: Do hcall_destroy_vm() before resource release

On Tue, Jul 27, 2021 at 10:47:58PM +0800, Greg Kroah-Hartman wrote:
> On Thu, Jul 22, 2021 at 02:27:36PM +0800, Fei Li wrote:
> > From: Shuo Liu <[email protected]>
> >
> > The ACRN hypervisor has scenarios which could run a real-time guest VM.
> > The real-time guest VM occupies dedicated CPU cores, be assigned with
> > dedicated PCI devices. It can run without the Service VM after boot up.
> > hcall_destroy_vm() returns failure when a real-time guest VM refuses.
> > The clearing of flag ACRN_VM_FLAG_DESTROYED causes some kernel resource
> > double-freed in a later acrn_vm_destroy().
> >
> > Do hcall_destroy_vm() before resource release to drop this chance to
> > destroy the VM if hypercall fails.
> >
> > Fixes: 9c5137aedd11 ("virt: acrn: Introduce VM management interfaces")
> > Signed-off-by: Shuo Liu <[email protected]>
> > Signed-off-by: Fei Li <[email protected]>
> > ---
>
> Do you also want this backported to older kernels? If so, you need to
> put a cc: stable in here, right? I'll go add it myself, but be more
> careful next time please.
yes, thanks for your kind reminder.
I will pay great attention next time.

>
> greg k-h