[PATCH 2/2] xen/sched: core: kill unarmed timers on sched_init_vcpu() failure

sched_init_vcpu() calls init_timer() for a vcpu's periodic_timer,
singleshot_timer and poll_timer before it can fail -- these
become live, linked into their target pCPU's per-cpu timer list
regardless of what happens next. If the sched_alloc_udata() call
further down then fails, the function frees the sched_unit via
sched_free_unit() and returns 1, but never unlinks these three
timers.

The caller, vcpu_create(), does worse: on sched_init_vcpu()
returning nonzero it jumps to fail_wq, skipping fail_sched and
thus sched_destroy_vcpu() -- the only function on this path that
calls kill_timer() on them. vcpu_destroy() then frees the vcpu,
and the three timers embedded in it, while they are still linked
into that shared list.

This silently corrupts that list. It only shows up later, when
something else touches a neighboring timer: sched_move_domain()
crashed with "Assertion 'entry->prev->next == entry' failed" on a
completely unrelated, valid vcpus's timer.

Kill all three timers in sched_init_vcpu()'s own failure branch,
so it doesn't depend on the caller reaching sched_destroy_vcpu()
to undo what it set up itself.

Signed-off-by: Furkan Caliskan <[email protected]>
---
 xen/common/sched/core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index d542c76543..f3ae9998ef 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -589,6 +589,9 @@ int sched_init_vcpu(struct vcpu *v)
     unit->priv = sched_alloc_udata(dom_scheduler(d), unit, d->sched_priv);
     if ( unit->priv == NULL )
     {
+        kill_timer(&v->periodic_timer);
+        kill_timer(&v->singleshot_timer);
+        kill_timer(&v->poll_timer);
         sched_free_unit(unit, v);
         rcu_read_unlock(&sched_res_rculock);
         return 1;
-- 
2.34.1