[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> 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().


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.