ipv4/tcp.c:4234:1: error: the frame size of 1152 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

[Nathan Chancellor]

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/

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