Re: [PATCH] mm/page_alloc: Fix zone reserve update serialization

[Michal Hocko]

On Mon 11-05-26 20:53:56, Muchun Song wrote:
> 
> 
> > On May 11, 2026, at 20:33, Michal Hocko <mhocko@xxxxxxxx> wrote:
> > 
> > On Mon 11-05-26 20:04:09, Muchun Song wrote:
> >> Serialize lowmem reserve and watermark updates with the same lock so
> >> calculate_totalreserve_pages() cannot observe partially updated zone
> >> reserve state.
> > 
> > Could you describe the problem you are facing?
> 
> To be more precise, commit 9726891fe753 moved 
> the call to setup_per_zone_lowmem_reserve into 
> adjust_managed_page_count. Since adjust_managed_page_count
> can be executed concurrently across multiple CPUs 
> (especially during memory hotplug or parallel initialization),
> I am concerned that this might lead to inconsistent updates for
> the following counters:
> 
>     zone->lowmem_reserve
>     pgdat->totalreserve_pages
>     The global totalreserve_pages
> 
> If these updates are not atomic or properly synchronized,
> the resulting values could be inaccurate. This inconsistency
> might cause issues for other kernel subsystems that rely on
> these reserve counts for memory allocation and reclamation
> decisions.
> 
> Just to clarify, I noticed this potential issue while reviewing
> the source code; it is not a bug I have encountered in a production
> environment yet.

This is important part that should be part of the changelog. Theoretical
issue observed when reading the code.
While it is really trivial to see that there is a race condition. It is
much less obvious whether the race condition actually matters and worth
fixing by introducing a new lock. So this needs much more explanation.
I am not against the patch but the changelog is quite underdocumented.

-- 
Michal Hocko
SUSE Labs