Re: [PATCH 1/1] x86/crash: reserve elfcorehdr for CONFIG_NR_CPUS, not CONFIG_NR_CPUS_DEFAULT

[Ionut Nechita (Wind River)]

On Fri, 14 Aug 2026 10:05:59 +0800, Jinjie Ruan wrote:
> Could we just use num_possible_cpus()?
>
> Either way, I think it's okay.
>
> Reviewed-by: Jinjie Ruan <ruanjinjie@xxxxxxxxxx>

Thanks for the review!

We could -- num_possible_cpus() is fixed after boot and bounded by
CONFIG_NR_CPUS, so it would give an exact (and slightly tighter)
reservation, and it matches what crash_prepare_elf64_headers() actually
iterates over (for_each_possible_cpu()).

I kept CONFIG_NR_CPUS on purpose, though:

  - It is the minimal fix for a Fixes:-tagged, stable-bound bug, and it
    just swaps the wrong compile-time constant (CONFIG_NR_CPUS_DEFAULT)
    for the correct compile-time upper bound (CONFIG_NR_CPUS), which
    keeps the change trivial to reason about and to backport.

  - It keeps the reservation expression homogeneous: in both branches
    the terms (2 + CONFIG_NR_CPUS + CONFIG_CRASH_MAX_MEMORY_RANGES) are
    all compile-time constants; mixing in a runtime value would be
    inconsistent with the neighbouring CRASH_MAX_MEMORY_RANGES term,
    which is also a compile-time bound rather than the actual number of
    memory ranges.

If you'd prefer the num_possible_cpus() variant I am happy to respin,
but otherwise I will keep v1 as-is and carry your Reviewed-by.

Thanks,
Ionut