]> xenbits.xensource.com Git - xen.git/commit
xen: credit2: use the correct scratch cpumask.
authorDario Faggioli <dario.faggioli@citrix.com>
Thu, 9 Feb 2017 09:31:26 +0000 (10:31 +0100)
committerJan Beulich <jbeulich@suse.com>
Thu, 9 Feb 2017 09:31:26 +0000 (10:31 +0100)
commit1f2fe766ce0fc6f3501eeebda9a8b1815e76f724
treeca99e5346bf8bd11653d7aaa0d83f3f00b4583f9
parent386acdbf8f1f21ef560dc343ec6c84b47b9168a2
xen: credit2: use the correct scratch cpumask.

In fact, there is one scratch mask per each CPU. When
you use the one of a CPU, it must be true that:
 - the CPU belongs to your cpupool and scheduler,
 - you own the runqueue lock (the one you take via
   {v,p}cpu_schedule_lock()) for that CPU.

This was not the case within the following functions:

get_fallback_cpu(), csched2_cpu_pick(): as we can't be
sure we either are on, or hold the lock for, the CPU
that is in the vCPU's 'v->processor'.

migrate(): it's ok, when called from balance_load(),
because that comes from csched2_schedule(), which takes
the runqueue lock of the CPU where it executes. But it is
not ok when we come from csched2_vcpu_migrate(), which
can be called from other places.

The fix is to explicitly use the scratch space of the
CPUs for which we know we hold the runqueue lock.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reported-by: Jan Beulich <JBeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
master commit: 548db8742872399936a2090cbcdfd5e1b34fcbcc
master date: 2017-01-24 17:02:07 +0000
xen/common/sched_credit2.c