Re: [PATCH] kho: fix global scratch size calculation

[Sourabh Jain]

On 22/09/26 18:57, sashiko-bot@xxxxxxxxxx wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] kho: lowmem scratch exhaustion due to missing node-specific lowmem reservations
> --
>
> commit 45b67db1813edaa6fb1bdfe7033f0598a814cd63
> Author: Sourabh Jain <sourabhjain@xxxxxxxxxxxxx>
>
> kho: fix global scratch size calculation
>
> This commit updates the scratch size calculations to correctly distinguish
> between memory reserved for a specific NUMA node and memory reserved with
> NUMA_NO_NODE. It introduces memblock_reserved_size_nid() to calculate
> reserved memory based on reservation type and NUMA node, fixing an issue
> where per-node reservations were incorrectly included in the global scratch
> allocation.
>
> > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> > index 7c4d86daf86d5..dc809e1e768c0 100644
> > --- a/kernel/liveupdate/kexec_handover.c
> > +++ b/kernel/liveupdate/kexec_handover.c
> [ ... ]
> > @@ -787,17 +787,17 @@ static void __init scratch_size_update(void)
> >   	if (scratch_scale) {
> >   		phys_addr_t size;
> >   
> > -		size = memblock_reserved_kern_size(ARCH_LOW_ADDRESS_LIMIT,
> > -						   NUMA_NO_NODE);
> > -		size -= memblock_reserved_hugetlb_size(ARCH_LOW_ADDRESS_LIMIT,
> > -						       NUMA_NO_NODE);
> > +		size = memblock_reserved_size_nid(ARCH_LOW_ADDRESS_LIMIT, NUMA_NO_NODE,
> > +						  MEMBLOCK_RSRV_KERN);
> [Severity: High]
> Does checking NUMA_NO_NODE here exclude node-specific lowmem reservations
> (like node-bound DMA pools) from the lowmem scratch size calculation?

No. Node-specific reservations are handled separately. The node-specific
scratch memory size is calculated in scratch_size_node(), so if the kernel
has made a node-specific allocation, KHO will reserve scratch memory on
the corresponding node.

> If the successor kernel requires lowmem for these node-specific reservations
> during early boot, could shrinking the global lowmem scratch memory lead to
> memblock allocation failures and a panic?


With this fix, KHO still reserves both per-node scratch memory and
lowmem scratch memory to meet the needs of the successor kernel.

Per-node scratch memory is reserved on the corresponding node.
The only change is that per-node allocations made in lowmem (below 4G 
by-default)
are no longer counted when calculating the lowmem scratch size.


> > +		size -= memblock_reserved_size_nid(ARCH_LOW_ADDRESS_LIMIT, NUMA_NO_NODE,
> > +						   MEMBLOCK_RSRV_HUGETLB);
> >   		size = size * scratch_scale / 100;
> >   		scratch_size_lowmem = size;
> [ ... ]
> > @@ -815,11 +815,11 @@ static phys_addr_t __init scratch_size_node(int nid)
> >   	phys_addr_t size;
> >   
> >   	if (scratch_scale) {
> > -		size = memblock_reserved_kern_size(MEMBLOCK_ALLOC_ANYWHERE,
> > -						   nid);
> > +		size = memblock_reserved_size_nid(MEMBLOCK_ALLOC_ANYWHERE, nid,
> > +						  MEMBLOCK_RSRV_KERN);
> [Severity: High]
> Are the node-specific lowmem reservations that were excluded from
> scratch_size_lowmem now being counted here instead? Since this counts
> with MEMBLOCK_ALLOC_ANYWHERE, will these reservations potentially be satisfied
> using scratch memory in highmem?

No.

> If the successor kernel restricts its memblock allocations to
> MEMBLOCK_KHO_SCRATCH regions, won't it be unable to recreate its
> node-specific lowmem reservations if the per-node scratch memory was placed
> in highmem?

The per-node scratch memory will be allocated on the corresponding
node. Therefore, the successor kernel should be able to recreate its
node-specific reservations, even if the per-node scratch memory is
placed in highmem.



> >   		/* Do not count HugeTLB pages. */
> > -		size -= memblock_reserved_hugetlb_size(MEMBLOCK_ALLOC_ANYWHERE,
> > -						       nid);
> > +		size -= memblock_reserved_size_nid(MEMBLOCK_ALLOC_ANYWHERE, nid,
> > +						   MEMBLOCK_RSRV_HUGETLB);
> >   		size = size * scratch_scale / 100;
> >   	} else {
> >   		size = scratch_size_pernode;