On 9/7/2021 4:14 PM, Linus Torvalds wrote:

There are many more of these cases. I've seen Hyper-V allocate 'struct
cpumask' on the stack, which is once again an absolute no-no that
people have apparently just ignored the warning for. When you have
NR_CPUS being the maximum of 8k, those bits add up, and a single
cpumask is 1kB in size. Which is why you should never do that on
stack, and instead use '

        cpumask_var_t mask;
        alloc_cpumask_var(&mask,..)

which will do a much more reasonable job. But the reason I call out
hyperv is that as far as I know, hyperv itself doesn't actually
support 8192 CPU's. So all that apic noise with 'struct cpumask' that
uses 1kB of data when NR_CPUS is set to 8192 is just wasted. Maybe I'm
wrong. Adding hyperv people to the cc too.

I am only commenting on this because I was looking into an instance of 
this warning yesterday with Fedora's arm64 config, which has 
CONFIG_NR_CPUS=4096:

https://lore.kernel.org/r/YTZyMx91zV9kfDkQ@Ryzen-9-3900X.localdomain/ (local)

Won't your example only fix the issue with CONFIG_CPUMASK_OFFSTACK=y or 
am I misreading the gigantic comment in include/linux/cpumask.h? As far 
as I can tell, only x86 selects it and it is not user configurable 
unless CONFIG_DEBUG_PER_CPU_MAPS is set, which is buried in the debug 
options so most people won't bother trying to enable it. If I understand 
correctly, how should these be dealt with in the case of 
CONFIG_CPUMASK_OFFSTACK=n?

Cheers,
Nathan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel