Re: [PATCH 11/13] percpu: fix contig hints that are too low

["Gregory Price (Meta)" <gourry@gourry.net>]

On 2026-11-11 18:13 +0000, Lorenzo Stoakes (ARM) wrote:
> pcpu_find_block_fit() skips a chunk or block whose contig_hint is too
> small for the request, so a contig_hint must never be smaller than the
> largest free area.
> 
> If it is, atomic and reserved chunk allocations can fail spuriously, and
> others can create a chunk which is not needed.
> 
> There are three ways in which this can happen:
> 
> Firstly, when an allocation breaks a contig_hint, both
> pcpu_block_refresh_hint() and pcpu_chunk_refresh_hint() promote the
> scan_hint to contig_hint and scan only what follows it. However a free
> can set the scan_hint regardless of what precedes it:
> 
>     free areas    A = 10 bits, then C = 50 bits
>     hints         contig_hint = C
>                   scan_hint = 0, cleared by an earlier allocation
>     free B        5 bits between A and C: scan_hint = B
>     allocate C    contig_hint = B, the scan starts after B
>     result        contig_hint = 5, but A has 10 bits
> 
> Secondly, when a free stays within one block,
> pcpu_block_update_hint_free() passes the end of the free area to the
> chunk hints as a block offset rather than a chunk offset, so in any block
> but the first the chunk hints are not updated at all.
> 
> Thirdly, that free area stops at the block boundary, even if the free
> bits continue into a neighbouring block.
> 
> Fix these by always rescanning when a contig_hint is broken, passing the
> correct offset, and refreshing the chunk hints whenever a free area
> reaches a block boundary.
> 
> Reported-by: Chris Mason <mason@kernel.org>
> Fixes: da3afdd5bb54 ("percpu: use block scan_hint to only scan forward")
> Fixes: 92c14cab4326 ("percpu: convert chunk hints to be based on pcpu_block_md")
> Fixes: d33d9f3dd96b ("percpu: use chunk scan_hint to skip some scanning")
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>

I was able to reproduce all three conditions and show the pcp allocator
will over-consume memory and in some cases fail allocations.

The change otherwise looks reasonable to me, falls into the class of
"Avoid doing clever things" camp, which i like.

Tested-by: Gregory Price (Meta) <gourry@gourry.net>
Reviewed-by: Gregory Price (Meta) <gourry@gourry.net>

-- 
~Gregory