From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-13.mta1.migadu.com [95.215.58.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3386533BBAF for ; Fri, 14 Aug 2026 03:42:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786678946; cv=none; b=WNeU3jYWlfCT3zs/DgtEZ9y/EfONUgkWgcwWziNqHpI6PC9cgOWUe3JvzhO0kFhmFz7sLOQKVwFJjoan47JDAfeYxB3kA2HvCnfSgZLfGBS+I3tcZ+MNVJ+WG08i5RksINj9FCu2hMRnRxNFKeAVg9ZY44qLvSTXSPb52pB5NNM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786678946; c=relaxed/simple; bh=SEkZgSN+NXcDybe67t2nMJKIlyyWBLCG1dqID552C8M=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=JQDFctUmIXp3quDdhgTe1D2wx57NH48gLucJgsmLyr8V37wR41DaK5oShMhGrEuqMV93Htz/5QZ1DKUERMcKu/H69PFor1OCwa9iI6i2g7D05L/Kb/iBhjuLD1abOEdN4FCZmhYGdNHRKQQKRo9Bnq6kk0Wpszz/w1MMvb9s0RU= 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=sSfvSPgA; arc=none smtp.client-ip=95.215.58.13 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="sSfvSPgA" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=SEkZgSN+NXcDybe67t2nMJKIlyyWBLCG1dqID552C8M=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786678942; v=1; x=1787283742; b=sSfvSPgAIlegcteFvyTTCEhNa5dtpER5JoZBySjm9A8v+sA9otQPvs8+4kPu9KyL/kmtbmus NSzbAEbEcCoPnugZOnZzbasFC4BPLmLaUZLxkg4afKMIcD+BliHJAFcUQE6rKZtBA7GyxHv7vNd UvlJ9fIPqPwVw42sp+BD6uLc= X-Envelope-To: linux-kernel@vger.kernel.org Received: from smtpclient.apple (114.251.196.97) by mta10.migadu.com with ESMTPS id e9ad8cb527641a7c; Fri, 14 Aug 2026 03:42:22 +0000 X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset=us-ascii Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Subject: Re: [PATCH v4 1/2] memcg: acquire peaks_lock when reading memory.peak From: Muchun Song In-Reply-To: <20260814033005.2481920-2-ridong.chen@linux.dev> Date: Fri, 14 Aug 2026 11:42:02 +0800 Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Andrew Morton , David Finkel , Tejun Heo , "open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)" , "open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)" , linux-kernel@vger.kernel.org, Tao Cui , Ridong Chen Content-Transfer-Encoding: quoted-printable Message-Id: <5511E37E-62E7-43E5-8A0D-BE95CC88359C@linux.dev> References: <20260814033005.2481920-1-ridong.chen@linux.dev> <20260814033005.2481920-2-ridong.chen@linux.dev> To: Ridong Chen X-Mailer: Apple Mail (2.3864.600.51.1.1) > On Aug 14, 2026, at 11:30, Ridong Chen wrote: >=20 > From: Ridong Chen >=20 > Sashiko reported that a reader can transiently observe a lower peak > within a race window [1]. peak_show() returns > max(local_watermark, ofp->value), but peak_write() updates those two > under peaks_lock while the reader takes no lock. The interleaving is: >=20 > writer (reset on fd A) reader (fd B) > ---------------------- ------------- > usage =3D page_counter_read(pc) > WRITE_ONCE(local_watermark, usage) > // watermark lowered to usage > lw =3D = READ_ONCE(local_watermark) > // sees the lowered usage > val =3D READ_ONCE(ofp->value) > // B's value not updated yet > return max(lw, val) > // both low -> low peak > WRITE_ONCE(peer_ctx->value, usage) > // B updated, but too late >=20 > Fix it by acquiring peaks_lock when reading the peak, so the reader = sees > a consistent snapshot of local_watermark and the per-fd values. The = same > race applies to memory.swap.peak, which shares peaks_lock and the > peak_write() path, so take the lock there as well. >=20 > [1] = https://sashiko.dev/#/patchset/20260730115314.1069089-1-ridong.chen@linux.= dev?part=3D1 > Fixes: c6f53ed8f213 ("mm, memcg: cg2 memory{.swap,}.peak write = handlers") > Assisted-by: Claude:claude-opus-4-8 > Signed-off-by: Ridong Chen > Acked-by: Johannes Weiner > Acked-by: Shakeel Butt Reviewed-by: Muchun Song Thanks