From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-169.mta0.migadu.com [91.218.175.169]) (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 E0A312EEE84 for ; Fri, 14 Aug 2026 01:29:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786670999; cv=none; b=ozec2nFW4pYbyvy9/wigDFjvNJ2CkNoXakY5bHEldCMn+lGHYO1O9QPH3BcaG8RlNFYbSsvrLqCnAfibNzqWH1mnX53/xPIBFJGtz7hEJbdu1yO6etpTXLFLMffj8fHd6kQxFlPmkGGq1TnWZnoEWmEpbJfTSWVlz6Z1L7vSXYU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786670999; c=relaxed/simple; bh=YRIK/awmx71exiVOjlgX7attdFmpDuckcomywEMtZlw=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=FlrhFU1JpqJa0DNIm2aLaHaAqKcAEYPHleWs4YnPUxIzOeRPUMvX4/m5EqcmHMpv3GicpkWlCXm7K/Mbmkv78E641qnBaq7qucuk2Gblp+MBOa5BDvFMun27jLYye24FLwkXRi2nm1PisvKSVEcgs7GBKx43CBOOfqZNxyAuG3c= 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=umpg/rpQ; arc=none smtp.client-ip=91.218.175.169 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="umpg/rpQ" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=YRIK/awmx71exiVOjlgX7attdFmpDuckcomywEMtZlw=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786670988; v=1; x=1787275788; b=umpg/rpQ0RnezST5AyWEhNrlGcp9Ihpe2PksMoQcWQDlXU4R8wBA/WB1e+ajFOSZkEjI3oPW 7Iww2O7O1qIoVY0nTOABHu0X/YM44axR0fC36fO1MBpC7acU3Zg1tf04P8K2+vl/bpDcI6fm+AI Sx8Mh1hddQEV5PGthp5Dx/oo= X-Envelope-To: linux-kernel@vger.kernel.org Received: from mi-ThinkCentre-M760t.mioffice.cn (14.29.108.92) by smtp.migadu.com with ESMTPS id bbd37d40f1c9974b; Fri, 14 Aug 2026 01:29:48 +0000 X-Migadu-Flow: FLOW_OUT From: Ridong Chen To: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Andrew Morton Cc: Muchun Song , Tejun Heo , David Finkel , =?UTF-8?q?Michal=20Koutn=C3=BD?= , cgroups@vger.kernel.org (open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)), linux-mm@kvack.org (open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)), linux-kernel@vger.kernel.org, Tao Cui , Ridong Chen , Ridong Chen Subject: [PATCH v3 1/2] memcg: acquire peaks_lock when reading memory.peak Date: Fri, 14 Aug 2026 09:29:23 +0800 Message-Id: <20260814012924.2388613-2-ridong.chen@linux.dev> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260814012924.2388613-1-ridong.chen@linux.dev> References: <20260814012924.2388613-1-ridong.chen@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Ridong Chen 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: writer (reset on fd A) reader (fd B) ---------------------- ------------- usage = page_counter_read(pc) WRITE_ONCE(local_watermark, usage) // watermark lowered to usage lw = READ_ONCE(local_watermark) // sees the lowered usage val = 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 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. [1] https://sashiko.dev/#/patchset/20260730115314.1069089-1-ridong.chen@linux.dev?part=1 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 --- mm/memcontrol.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 17da1f43b7d3..6dd8756870ff 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -4713,8 +4713,13 @@ static int peak_show(struct seq_file *sf, void *v, struct page_counter *pc) static int memory_peak_show(struct seq_file *sf, void *v) { struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(sf)); + int ret; - return peak_show(sf, v, &memcg->memory); + spin_lock(&memcg->peaks_lock); + ret = peak_show(sf, v, &memcg->memory); + spin_unlock(&memcg->peaks_lock); + + return ret; } static int peak_open(struct kernfs_open_file *of) @@ -5858,8 +5863,13 @@ static u64 swap_current_read(struct cgroup_subsys_state *css, static int swap_peak_show(struct seq_file *sf, void *v) { struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(sf)); + int ret; - return peak_show(sf, v, &memcg->swap); + spin_lock(&memcg->peaks_lock); + ret = peak_show(sf, v, &memcg->swap); + spin_unlock(&memcg->peaks_lock); + + return ret; } static ssize_t swap_peak_write(struct kernfs_open_file *of, char *buf, -- 2.34.1