8fde1a8070
Since commit7b55e47e1d("Restore CPU affinity patches' functionality"), the function kthread_setup() has allocated a cpumask structure on the stack, which uses 1024 bytes on the stack when CONFIG_MAXSMP is enabled. This was detected after setting CONFIG_FRAME_WARN to 1024 for testing purposes. To clarify, with the following configuration: $ grep -e MAXSMP= -e NR_CPUS= -e CPUMASK_OFFSTACK= \ -e FRAME_WARN= .config CONFIG_MAXSMP=y CONFIG_NR_CPUS=8192 CONFIG_CPUMASK_OFFSTACK=y CONFIG_FRAME_WARN=1024 the following build warning is encountered: CC kernel/cpu.o kernel/cpu.c: In function 'kthread_setup': kernel/cpu.c:2475:1: warning: the frame size of 1032 bytes is \ larger than 1024 bytes [-Wframe-larger-than=] This commit resolves this issue by allocating the cpumask structure using the boot memory allocator via alloc_bootmem_cpumask_var(). A similar approach is taken for the housekeeping-related cpumask structures in kernel/sched/isolation.c. Please note that the issue fixed by this commit (large stack allocation) only exists when CONFIG_CPUMASK_OFFSTACK is enabled. StarlingX currently disables CONFIG_CPUMASK_OFFSTACK. Disabling CONFIG_CPUMASK_OFFSTACK sets CONFIG_NR_CPUS' maximum value to 512 CPUs, which in turn corresponds to 64 bytes on the stack. In contrast, enabling CONFIG_CPUMASK_OFFSTACK (for example, by setting CONFIG_MAXSMP=y) raises the upper limit for CONFIG_NR_CPUS to 8192 CPUs, which translates to a 1024-byte bitmap. No change in behaviour is intended. While carrying out the code changes, space characters in the affected function were converted to tab characters as a minor clean-up. Testing: * Monolithic ISO image build was successful. * Installation and bootstrap of the built ISO was successful with a virtual machine in All-in-One simplex mode, using the low-latency profile. * kthread_cpus argument's behaviour was confirmed to not have been negatively affected by checking that the CPU affinity of kthreadd (i.e., pid 2) matches the kthread_cpus= argument's value. * kthread_cpus argument's error handling was confirmed to work as expected by booting up the installed system with an invalid argument ('kthread_cpus=abc'). In this scenario, the CPU affinity of kthreadd was observed to be correctly set to 0-7 (with an 8-CPU VM). Change-Id: I31d2175d6084142e63d4b38d7b0c5677046fce4f Closes-Bug: 1957188 Fixes:7b55e47e1d("Restore CPU affinity patches' functionality") Signed-off-by: M. Vefa Bicakci <vefa.bicakci@windriver.com>