From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-173.mta0.migadu.com (out-173.mta0.migadu.com [91.218.175.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 ACE1C3A1CE6 for ; Mon, 11 May 2026 13:12:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778505140; cv=none; b=QyG+rCpk5jJz8KD4P0auuG3VSIwtS2PPeGbj2dzEMAvWKHlMgJO48R558AwhRprH64uVREkQM8Y06UoKSoUNPH17q/rH/6Ov5KqzsJz6HKguKE1XCVAkdcSgpW3SqQXpQ2GOuOP+eO+61gkMSFZt70000yxvRMUg1Su2HaJOU40= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778505140; c=relaxed/simple; bh=mHvnu5AukFcsEUrsGUCRlDY4a+nzAkU1aw936njlQb8=; h=Content-Type:From:Mime-Version:Subject:Date:Message-Id:References: Cc:In-Reply-To:To; b=juDLiueEPrb4NRtAf3IBU1WjIdEyIaalNCB8Ed6G/oTakE3NzawVFqpb4iUGiSSeKuYueLfkepG0KMgSGu5ilda6gWWHkyrshaHh2cP27IhfEhHID1oLhuwId98WQ612pMvgDDrP1s0zzoW+pGaYobBe7LpnoyVXN1czFp/MW8E= 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=ivtk2zlG; arc=none smtp.client-ip=91.218.175.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="ivtk2zlG" Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1778505135; 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=+BOMHgDECiBc18kMy1bAnOxhSlWyxw7BIMrtd1bfCJI=; b=ivtk2zlGe2VZOVHnnWCntXpOrUVGdOXN9qd7oWbdCxRiDKaF8nRbDymDMS6jbIAkY+qD6i tQ8Qw0lRgv06A1XdPxz4BSz+FgtWvU5mjrIl8sG9+cIcTmLDxHklKLws0ORaQcrWcSU2xM SviTM3Lkh9oaqg56vhT0K4dwcxb4SzM= 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 21:11:40 +0800 Message-Id: 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 21:00, Michal Hocko wrote: >=20 > =EF=BB=BFOn Mon 11-05-26 20:53:56, Muchun Song wrote: >>=20 >>=20 >>>> 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? >>=20 >> 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: >>=20 >> zone->lowmem_reserve >> pgdat->totalreserve_pages >> The global totalreserve_pages >>=20 >> 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. >>=20 >> 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. >=20 > 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=E2=80=99ll update a version with more precise information in the c= ommit. Thanks, Muchun >=20 > -- > Michal Hocko > SUSE Labs