[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH v2 1/6] cpupools: fix state when downing a CPU failed
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 <jbeulich@xxxxxxxx> --- v2: Move change into cpupool_cpu_add(). Adjust conditional there. --- a/xen/common/cpupool.c +++ b/xen/common/cpupool.c @@ -490,7 +490,7 @@ static int cpupool_cpu_add(unsigned int cpumask_clear_cpu(cpu, &cpupool_locked_cpus); cpumask_set_cpu(cpu, &cpupool_free_cpus); - if ( system_state == SYS_STATE_resume ) + if ( system_state == SYS_STATE_suspend || system_state == SYS_STATE_resume ) { struct cpupool **c; @@ -522,6 +522,7 @@ static int cpupool_cpu_add(unsigned int * (or unplugging would have failed) and that is the default behavior * anyway. */ + per_cpu(cpupool, cpu) = NULL; ret = cpupool_assign_cpu_locked(cpupool0, cpu); } out: _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |