Re: [PATCH] Avoid race when moving cpu between cpupools

[Keir Fraser <keir.xen@gmail.com>]

On 25/02/2011 14:25, "Andre Przywara" <andre.przywara@amd.com> wrote:

> can you rule out that this code will be triggered on two CPUs trying to
> switch to each other? As Stephan pointed out: the code looks like as
> this could trigger a possible dead-lock condition, where:
> 1) CPU A grabs lock (a) while CPU B grabs lock (b)
> 2) CPU A tries to grab (b) and CPU B tries to grab (a)
> 3) both fail and loop to 1)
> A possible fix would be to introduce some ordering for the locks (just
> the pointer address) and let the "bigger" pointer yield to the "smaller"
> one. I am not sure if this is really necessary, but I now see strange
> hangs after running the script for a while (30min to 1hr).
> Sometimes Dom0 hangs for a while, loosing interrupts (sda or eth0) or
> getting spurious ones, on two occasions the machine totally locked up.

In other places in Xen where we take a pair of locks with no other implicit
ordering, we enforce an ordering based lock addresses. See
common/timer.c:migrate_timer() for example. I'm sure there must be at least
one example of this in the schedulign code already, with vcpus migrating
between cpus and needing both runqueue locks.

 -- Keir