Re: [PATCH] xen: sched/Credit2: fix bug when moving CPUs between two Credit2 cpupools

[Juergen Gross <jgross@suse.com>]

On 13/09/18 13:53, Dario Faggioli wrote:
> Whether or not a CPU is assigned to a runqueue (and, if yes, to which
> one) within a Credit2 scheduler instance must be both a per-cpu and
> per-scheduler instance one.
> 
> In fact, when we move a CPU between cpupools, we first setup its per-cpu
> data in the new pool, and then cleanup its per-cpu data from the old
> pool. In Credit2, when there currently is no per-scheduler, per-cpu
> data (as the cpu-to-runqueue map is stored on a per-cpu basis only),
> this means that the cleanup of the old per-cpu data can mess with the
> new per-cpu data, leading to crashes like this:
> 
> https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg23306.html
> https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg23350.html
> 
> Basically, when csched2_deinit_pdata() is called for CPU 13, for fully
> removing the CPU from Pool-0, per_cpu(13,runq_map) already contain the
> id of the runqueue to which the CPU has been assigned in the scheduler
> of Pool-1, which means wrong runqueue manipulations happen in Pool-0's
> scheduler. Furthermore, at the end of such call, that same runq_map is
> updated with -1, which is what causes the BUG_ON in csched2_schedule(),
> on CPU 13, to trigger.
> 
> So, instead of reverting a2c4e5ab59d "xen: credit2: make the cpu to
> runqueue map per-cpu" (as we don't want to go back to having the huge
> array in struct csched2_private) add a per-cpu scheduler specific data
> structure, like, for instance, Credit1 has already. That (for now) only
> contains one field: the id of the runqueue the CPU is assigned to.
> 
> Signed-off-by: Dario Faggioli <dfaggioli@suse.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel