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

[Muchun Song]

> On May 11, 2026, at 21:00, Michal Hocko <mhocko@xxxxxxxx> wrote:
> 
> 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.

Got it. I’ll update a version with more precise information in the commit.

Thanks,
Muchun

> 
> --
> Michal Hocko
> SUSE Labs