On 18/07/18 10:18, Jan Beulich wrote:
> While I've run into the issue with further patches in place which no
> longer guarantee the per-CPU area to start out as all zeros, the
> CPU_DOWN_FAILED processing looks to have the same issue: By not zapping
> the per-CPU cpupool pointer, cpupool_cpu_add()'s (indirect) invocation
> of schedule_cpu_switch() will trigger the "c != old_pool" assertion
> there.
> 
> Clearing the field during CPU_DOWN_PREPARE is too early (afaict this
> should not happen before cpu_disable_scheduler()). Clearing it in
> CPU_DEAD and CPU_DOWN_FAILED would be an option, but would take the same
> piece of code twice. Since the field's value shouldn't matter while the
> CPU is offline, simply clear it (implicitly) for CPU_ONLINE and
> CPU_DOWN_FAILED, but only for other than the suspend/resume case (which
> gets specially handled in cpupool_cpu_remove()).
> 
> By adjusting the conditional in cpupool_cpu_add() CPU_DOWN_FAILED
> handling in the suspend case should now also be handled better.
> 
> Signed-off-by: Jan Beulich <[email protected]>

Reviewed-by: Juergen Gross <[email protected]>


Juergen

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to