From: Muchun Song <muchun.song@linux.dev>
To: Michal Hocko <mhocko@suse.com>
Cc: Muchun Song <songmuchun@bytedance.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@kernel.org>,
linux-mm@kvack.org, Suren Baghdasaryan <surenb@google.com>,
Brendan Jackman <jackmanb@google.com>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>,
zihan zhou <15645113830zzh@gmail.com>,
yaowenchao <yaowenchao@jd.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/page_alloc: Fix zone reserve update serialization
Date: Mon, 11 May 2026 20:53:56 +0800 [thread overview]
Message-ID: <53EC8695-885F-4C47-A9E9-89CCF963F0F3@linux.dev> (raw)
In-Reply-To: <agHMhEBAz9sol3TP@tiehlicka>
> On May 11, 2026, at 20:33, Michal Hocko <mhocko@suse.com> 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.
Thanks,
Muchun
>
>> Fixes: 9726891fe753 ("mm: page_alloc: fix missed updates of lowmem_reserve in adjust_managed_page_count")
>> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
>> ---
>> mm/page_alloc.c | 10 ++++++----
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 3a56825a7fc5..0989067da588 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -6384,6 +6384,8 @@ static void calculate_totalreserve_pages(void)
>> trace_mm_calculate_totalreserve_pages(totalreserve_pages);
>> }
>>
>> +static DEFINE_SPINLOCK(zone_reserve_lock);
>> +
>> /*
>> * setup_per_zone_lowmem_reserve - called whenever
>> * sysctl_lowmem_reserve_ratio changes. Ensures that each zone
>> @@ -6394,6 +6396,8 @@ static void setup_per_zone_lowmem_reserve(void)
>> {
>> struct pglist_data *pgdat;
>> enum zone_type i, j;
>> +
>> + guard(spinlock_irqsave)(&zone_reserve_lock);
>> /*
>> * For a given zone node_zones[i], lowmem_reserve[j] (j > i)
>> * represents how many pages in zone i must effectively be kept
>> @@ -6509,11 +6513,9 @@ static void __setup_per_zone_wmarks(void)
>> void setup_per_zone_wmarks(void)
>> {
>> struct zone *zone;
>> - static DEFINE_SPINLOCK(lock);
>>
>> - spin_lock(&lock);
>> - __setup_per_zone_wmarks();
>> - spin_unlock(&lock);
>> + scoped_guard(spinlock_irqsave, &zone_reserve_lock)
>> + __setup_per_zone_wmarks();
>>
>> /*
>> * The watermark size have changed so update the pcpu batch
>>
>> base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
>> --
>> 2.54.0
>
> --
> Michal Hocko
> SUSE Labs
next prev parent reply other threads:[~2026-05-11 12:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 12:04 [PATCH] mm/page_alloc: Fix zone reserve update serialization Muchun Song
2026-05-11 12:33 ` Michal Hocko
2026-05-11 12:53 ` Muchun Song [this message]
2026-05-11 13:00 ` Michal Hocko
2026-05-11 13:11 ` Muchun Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53EC8695-885F-4C47-A9E9-89CCF963F0F3@linux.dev \
--to=muchun.song@linux.dev \
--cc=15645113830zzh@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=songmuchun@bytedance.com \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=yaowenchao@jd.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox