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

From: Gregory Price (Meta)

Date: Thu Nov 12 2026 - 14:31:15 EST


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@xxxxxxxxxx>
> 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@xxxxxxxxxx>

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@xxxxxxxxxx>
Reviewed-by: Gregory Price (Meta) <gourry@xxxxxxxxxx>

--
~Gregory