Re: [Xen-devel] [PATCH v2] x86/hpet: Fix possible ASSERT(cpu < nr_cpu_ids)

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.04.18 at 11:25, <Davidwang@xxxxxxxxxxx> wrote:
> From: David Wang <davidwang@xxxxxxxxxxx>
> 
> For the ch->cpumask be cleared by other cpu, cpumask_first() called by
> hpet_detach_channel() return nr_cpu_ids. That lead an assertion in
> set_channel_irq_affinity() when cpumask_of() check cpu.
> Fix this by using a local variable.

The fix isn't to use a local variable, introducing a local variable is only a
vehicle for addressing the bug. Also I'm afraid I still can't make much
sense of the first sentence; it only is that now I know what you want
to fix.

> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -509,15 +509,18 @@ static void hpet_attach_channel(unsigned int cpu,
>  static void hpet_detach_channel(unsigned int cpu,
>                                  struct hpet_event_channel *ch)
>  {
> +    cpumask_t cpumask;

No, certainly not. We don't want variables of that type on the stack.
Recall that in v1 review I wrote "how about eliminating the
cpumask_empty() call in favor of just the cpumask_first()". The local
variable to introduce is to hold the result of cpumask_first().

Jan



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