From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-173.mta1.migadu.com (out-173.mta1.migadu.com [95.215.58.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF24336F433 for ; Mon, 11 May 2026 12:54:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778504082; cv=none; b=X+Rv6uMM2sQaXylC9g86pisurW9BmaBNxjpwhks5t4JtlfdZMPO0x1g3v935+VTEeiU0xoymI5pOyEVmGoYSSHLBKL0oP2DpIKSTUDvwqeD9kTvbyHM99GSh8eQgbpiESkTuVdjjiPWnSqe5qIhHFU4RjNk8TfpHEdAKw+TQo+A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778504082; c=relaxed/simple; bh=5nrAhd4wC7D4EwmnNpcao6hcfKmjMtj6BRUb7Esuygw=; h=Content-Type:From:Mime-Version:Subject:Date:Message-Id:References: Cc:In-Reply-To:To; b=YGau31YNvmNmX6r8oVBp5omgGq5+WmVfPlRVa/meydDtJPZVAFCFX2mhbyS1XOGXe3vULRF7Sfmh0AgAlJToFkfXeLTjK1lnqCE0k4LD6Haf89KDc+6+aySVgfVLBDRtYyh5i582ud2R6qGvD1RxSEKQI1vHX9hLRZlPX/ogHtk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=sbpqbv2C; arc=none smtp.client-ip=95.215.58.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="sbpqbv2C" Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1778504077; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yU4WyVP1Mc1o29qOhDo9PXkBl2LW5fnvyjnZvXOiIOw=; b=sbpqbv2ClrNkenLof3b/K8Xm89e1ShzTAaIfv0wK1jWc3QJ5YghHk4dpAwaILFARP5zrLW vaoat63FrYTYxVbkC+5RlEFHs/NDJkii+HE0cOwHg2uTGl8SD8znKycZKfzsFgIaur5KqU e0mFOGJ2BAJBvHnjSPPPlPxvd6o9Kh0= Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] mm/page_alloc: Fix zone reserve update serialization Date: Mon, 11 May 2026 20:53:56 +0800 Message-Id: <53EC8695-885F-4C47-A9E9-89CCF963F0F3@linux.dev> References: Cc: Muchun Song , Andrew Morton , Vlastimil Babka , linux-mm@kvack.org, Suren Baghdasaryan , Brendan Jackman , Johannes Weiner , Zi Yan , zihan zhou <15645113830zzh@gmail.com>, yaowenchao , linux-kernel@vger.kernel.org In-Reply-To: To: Michal Hocko X-Migadu-Flow: FLOW_OUT > On May 11, 2026, at 20:33, Michal Hocko wrote: >=20 > =EF=BB=BFOn 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. >=20 > Could you describe the problem you are facing? To be more precise, commit 9726891fe753 moved=20 the call to setup_per_zone_lowmem_reserve into=20 adjust_managed_page_count. Since adjust_managed_page_count can be executed concurrently across multiple CPUs=20 (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 >=20 >> Fixes: 9726891fe753 ("mm: page_alloc: fix missed updates of lowmem_reserv= e in adjust_managed_page_count") >> Signed-off-by: Muchun Song >> --- >> mm/page_alloc.c | 10 ++++++---- >> 1 file changed, 6 insertions(+), 4 deletions(-) >>=20 >> 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); >> } >>=20 >> +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); >>=20 >> - spin_lock(&lock); >> - __setup_per_zone_wmarks(); >> - spin_unlock(&lock); >> + scoped_guard(spinlock_irqsave, &zone_reserve_lock) >> + __setup_per_zone_wmarks(); >>=20 >> /* >> * The watermark size have changed so update the pcpu batch >>=20 >> base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83 >> -- >> 2.54.0 >=20 > -- > Michal Hocko > SUSE Labs