On 11/04/2019 11:55, Jan Beulich wrote: >>>> On 11.04.19 at 12:47, <andrew.coop...@citrix.com> wrote: >> On 11/04/2019 11:45, Jan Beulich wrote: >>> @@ -648,6 +646,8 @@ static int cpu_callback( >>> case CPU_UP_CANCELED: >>> case CPU_DEAD: >>> case CPU_RESUME_FAILED: >>> + migrate_timers_from_cpu(cpu); >>> + >>> if ( !park_offline_cpus && system_state != SYS_STATE_suspend ) >>> free_percpu_timers(cpu); >>> break; >> I'm pretty sure you also need a call in the REMOVE_CASE. The cpu comes >> online for long enough to potentially gain a timer. > What do you mean by "comes online for long enough"? There's > no call site for the notifier with CPU_REMOVE right now, so what > the eventual behavior is going to be is simply unknown. I for one > don't expect the CPU to be brought back up again in that case. > I'm wondering if you're mixing this up with CPU_RESUME_FAILED.
Now I'm even more confused, but yes clearly - it wasn't the CPU_REMOVE case. That said, by making this adjustment, you are now liable to hit an assertion in the REMOVE case, which on a release build will result in complete memory corruption, as it frees an in-use datastructure. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
