Dario Faggioli writes ("[PATCH] xen: fix for_each_cpu when NR_CPUS=1"):
> When running an hypervisor build with NR_CPUS=1 for_each_cpu does not
> take into account whether the bit of the CPU is set or not in the
> provided mask.
>
> This means that whatever we have in the bodies of these loops is always
> done once, even if the mask was empty and it should never be done. This
> is clearly a bug and was in fact causing an assert to trigger in credit2
> code.
>
> Removing the special casing of NR_CPUS == 1 makes things work again.
Release-Acked-by: Ian Jackson <i...@xenproject.org>
> I'm not really sure whether this should be 4.15 material.
>
> It's definitely a bug, IMO. The risk is also pretty low, considering
> that no one should really run Xen in this configuration (NR_CPUS=1, I
> mean). Which is also the reason why it's probably not really important
> that we fix it at this point of the release cycle.
Given that it clearly only affects NR_CPUS==1, I think the risk/reward
tradeoff is unambiguously positive.
> -#if NR_CPUS > 1
> #define for_each_cpu(cpu, mask) \
> for ((cpu) = cpumask_first(mask); \
Just a thought: does cpumask_first work on an empty mask ?
Ian.
