[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[xen staging-4.12] x86: fix resource leaks on arch_vcpu_create() error path



commit f49fff9072dff199a4e76ed27a3bd0b384b55e37
Author:     Jan Beulich <jbeulich@xxxxxxxx>
AuthorDate: Tue Oct 20 15:05:57 2020 +0200
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Tue Oct 20 15:05:57 2020 +0200

    x86: fix resource leaks on arch_vcpu_create() error path
    
    {hvm,pv}_vcpu_initialise() have always kind of been meant to be the
    final possible source of errors in arch_vcpu_create(), hence not
    requiring any unrolling of what they've done on the error path. (Of
    course this may change once the various involved paths all have become
    idempotent.)
    
    But even beyond this aspect I think it is more logical to do policy
    initialization ahead of the calling of these two functions, as they may
    in principle want to access it.
    
    Fixes: 4187f79dc718 ("x86/msr: introduce struct msr_vcpu_policy")
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: 6a34e67c118408ebdd62bfa7be76598ca040f170
    master date: 2020-10-14 14:03:38 +0200
---
 xen/arch/x86/domain.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 019dc57459..d5ebfbb83a 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -359,6 +359,9 @@ int arch_vcpu_create(struct vcpu *v)
         vmce_init_vcpu(v);
 
         arch_vcpu_regs_init(v);
+
+        if ( (rc = init_vcpu_msr_policy(v)) )
+            goto fail;
     }
     else if ( (rc = xstate_alloc_save_area(v)) != 0 )
         return rc;
@@ -384,9 +387,6 @@ int arch_vcpu_create(struct vcpu *v)
     {
         vpmu_initialise(v);
 
-        if ( (rc = init_vcpu_msr_policy(v)) )
-            goto fail;
-
         cpuid_policy_updated(v);
     }
 
--
generated by git-patchbot for /home/xen/git/xen.git#staging-4.12



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.