aboutsummaryrefslogtreecommitdiff
path: root/rust/compiler_builtins.rs
diff options
context:
space:
mode:
authorOleg Nesterov <[email protected]>2024-04-13 16:17:46 +0200
committerIngo Molnar <[email protected]>2024-04-28 10:08:21 +0200
commit257bf89d84121280904800acd25cc2c444c717ae (patch)
tree77885bdc1eb9b3d3d7bd1b93de4c9fad7954102a /rust/compiler_builtins.rs
parent5097cbcb38e6e0d2627c9dde1985e91d2c9f880e (diff)
sched/isolation: Fix boot crash when maxcpus < first housekeeping CPU
housekeeping_setup() checks cpumask_intersects(present, online) to ensure that the kernel will have at least one housekeeping CPU after smp_init(), but this doesn't work if the maxcpus= kernel parameter limits the number of processors available after bootup. For example, a kernel with "maxcpus=2 nohz_full=0-2" parameters crashes at boot time on a virtual machine with 4 CPUs. Change housekeeping_setup() to use cpumask_first_and() and check that the returned CPU number is valid and less than setup_max_cpus. Another corner case is "nohz_full=0" on a machine with a single CPU or with the maxcpus=1 kernel argument. In this case non_housekeeping_mask is empty and tick_nohz_full_setup() makes no sense. And indeed, the kernel hits the WARN_ON(tick_nohz_full_running) in tick_sched_do_timer(). And how should the kernel interpret the "nohz_full=" parameter? It should be silently ignored, but currently cpulist_parse() happily returns the empty cpumask and this leads to the same problem. Change housekeeping_setup() to check cpumask_empty(non_housekeeping_mask) and do nothing in this case. Signed-off-by: Oleg Nesterov <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Phil Auld <[email protected]> Acked-by: Frederic Weisbecker <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Diffstat (limited to 'rust/compiler_builtins.rs')
0 files changed, 0 insertions, 0 deletions