From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) (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 ABFBF43C7C5 for ; Wed, 12 Aug 2026 16:48:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786553326; cv=none; b=qaPHccyh+V2FQNsLDB4wVo8uLObRjVZJteH5Wuz7H2+vxAAmtnsBz490Kzei83sXw/zqoJZEfMtohSrGRjoiS0oqpgbuHzbs2nr35nfVYnPkhJLgpj5Awrk10qw4d6Ha7aGPioe5YE7nAJqsiqEDaSNo/nPQfB1Ux5kqJMJDfOo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786553326; c=relaxed/simple; bh=ehGxUwHNzBc2FQxNXfwVF1AexYOK+Dgj6vQjPhOYxwk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CZAqYKYEnArXhTk+qWdDmlRajTZzjXoxGglhytb75Om5g2kwQapUmjnmX1eM9n2edUmz9UURNLfWgGQZcD+Y6KPRZnS7e/0blGcqM7q2xHXqBiT/HCm76w/ApaA4cq3Z0sP1TP6iZcN6VD0yxcsMEe8MlUtgZiJBCeFakxOZwK0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=g81A9IU1; arc=none smtp.client-ip=209.85.219.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="g81A9IU1" Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-9061a795d76so12840256d6.3 for ; Wed, 12 Aug 2026 09:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1786553313; x=1787158113; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=eJWnk/M4buJ0YbJEsu331nsW/cLwTebx/mZLjvLX5Ns=; b=g81A9IU17G7xAJVLr4s2osC5jMl7n2WqsnZ/KQvlWfiH9x9leW0e8jn6i6NzEhViiK rYqb7bhLd7CTuWsqiyGNSvT0pBl1gecvfVe5m53pUDHAD87guUnZlHVqv92EoCx+vrRr gw+D+uSxzFVgc5fUyWYcE/cdhJTr3GBbaLFRWTca0rTj//lM9nFQLJ//PpaoLxJIogkK /ODWQuI/2ZGY5tTljsHSnp3/UkWn4nK9xdDfNl3aY2cEFQMo/2fLa5gIHu88sBghc1HK b8ZN/TbGr5Z1QQfCErts+6PjehGiapjYz+UttbePuEdu9Qz74p/+gZ0+Zx5LWpolEc7x wv6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786553313; x=1787158113; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=eJWnk/M4buJ0YbJEsu331nsW/cLwTebx/mZLjvLX5Ns=; b=ri46KNm1E0dDjisikIILStv7gMqrSmL+QRU702lqtpHZZNUjjGe7BCgK820HSNyuJQ ebEx5ZIltj7N3/Cape3kJcUysLsZ06M12g6qL/XF9dVP7NNENo2JDz5snmFi/v5ejiQC vFRoJkG/hJ4JB15bx75TzMFFJ/MV44csy4GU1MvMH2Y+UIln2p+g11ME8l3WdCDFHE8r I0ZqY+fBEJ4Xpd91kDX6c11DnvBESKY5U9xUgASZxo5rzzGLYJUEJKz1URkOPio/2zop rF/1qDtJBhK10s8gUetWEVgTwa+05BzAeamxbNE+nmexymY+40UJGliq2ciICppqNQTQ s0jg== X-Forwarded-Encrypted: i=1; AHgh+Rq0etjKYULc+cbigt2FqRyQ4VL9akugHOQuYRHlGtmmbtBh1ctbepC8rBz709ZE5FDMsYLEmuagkv3N/08=@vger.kernel.org X-Gm-Message-State: AOJu0Yy93r3wiePn8ONmGBK9SMqyf1y94ZpYnSoP5lX9B3rlg4WaF47G nPp0Ps0dzKjGBMaT49ug1r0rQmlsGdt+Imd10+wPcCZdOCq8pTPPLesopgjFHYY0Dcz6f7RM052 +sPoH X-Gm-Gg: AR+sD13hQVz57GH1Vbjn2GEsPGHpvj08s9OdXrFdA70NqCoIutU0+8Y4OnhNAEZXp6N A2kxFrk9FwQ2DK7xW75d7b5ynHawgNZnAzSSjp5rBrKXHpLLn+AmofPb1tQRa29CUtWAoCko2IE 2ZL+BNK2xCeZ5J2CrQfrVONrhiR9HGqcPS9p6BdqYWpNFbYyoXoW7AbvKhtUPmlHDfJqWZQx8Qe cmc+5BAl5A8mMgjpz+bRfWDI+HEoEqdE5N8QUx7Y2c2iMWwzqqlhCHAgwiFNuDfLmSglYmH2Ep0 SaiYSFGVUgMvw9ASoNA6poyAn2PQkhYODGAZEBDpotgArZKv4xp6kHdINpqtTnBhtM90UAh2eCS ZTwzMe4TUA5uUaePcl0E4me354942seD6phj4yZ80VzsaJP6k/ChFhi9DP4zuzHR1FpGcQ7sKpG /bwhndqT96MtO4bPp0ctY+NOIxo/4Uf2d7ZTLz96OFw2Jbmg9NeyYKwNx6z4fk/XenXpkPCg== X-Received: by 2002:a05:6214:492:b0:8f0:a849:f392 with SMTP id 6a1803df08f44-90a6ff45bdcmr55143356d6.14.1786553313548; Wed, 12 Aug 2026 09:48:33 -0700 (PDT) Received: from localhost ([2603:7001:f100:500:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-90a6c2cdcebsm24786266d6.21.2026.08.12.09.48.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Aug 2026 09:48:32 -0700 (PDT) Date: Wed, 12 Aug 2026 12:48:32 -0400 From: Johannes Weiner To: Ridong Cc: Michal Hocko , Roman Gushchin , Shakeel Butt , Andrew Morton , Muchun Song , Tejun Heo , Michal =?iso-8859-1?Q?Koutn=FD?= , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cui.tao@linux.dev, Ridong Chen Subject: Re: [PATCH v2 2/2] mm, memcg: fix memory.peak reset clobbering other fds' watermark Message-ID: References: <20260807090000.1532495-1-ridong.chen@linux.dev> <20260807090000.1532495-3-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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260807090000.1532495-3-ridong.chen@linux.dev> On Fri, Aug 07, 2026 at 05:00:00PM +0800, Ridong wrote: > From: Ridong Chen > > Writing to memory.peak resets the peak for that fd only. Each fd is a > watcher and reads back max(its own value, the shared local_watermark). > > peak_write() resets by lowering local_watermark to the current usage. > To keep the other watchers' peaks it then walks the watcher list, but it > stores the current usage into them instead of the old watermark. So once > usage has dropped from a peak, a reset on one fd wrongly drags every > other fd's peak down too, even fds that never reset. > > Reproduced on 7.2.0-rc5-next under QEMU, two fds A and B on one cgroup: > B sees the peak (410624 KB), usage drops, then A resets -- and B's peak > collapses to 1060 KB although B never reset. With this patch B keeps > reading 410624 KB. > > Fix: save the old watermark before lowering it and use that to floor the > other watchers, so a reset only affects the fd that issued it. > > Fixes: c6f53ed8f213 ("mm, memcg: cg2 memory{.swap,}.peak write handlers") > Assisted-by: Claude:claude-opus-4-8 > Signed-off-by: Ridong Chen > --- > mm/memcontrol.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 2da55b778ae3..28577beeb3d0 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -4746,7 +4746,7 @@ static ssize_t peak_write(struct kernfs_open_file *of, char *buf, size_t nbytes, > loff_t off, struct page_counter *pc, > struct list_head *watchers) > { > - unsigned long usage; > + unsigned long usage, peer_watermark; > struct cgroup_of_peak *peer_ctx; > struct mem_cgroup *memcg = mem_cgroup_from_css(of_css(of)); > struct cgroup_of_peak *ofp = of_peak(of); > @@ -4754,11 +4754,12 @@ static ssize_t peak_write(struct kernfs_open_file *of, char *buf, size_t nbytes, > spin_lock(&memcg->peaks_lock); > > usage = page_counter_read(pc); > + peer_watermark = max(usage, READ_ONCE(pc->local_watermark)); > WRITE_ONCE(pc->local_watermark, usage); > > list_for_each_entry(peer_ctx, watchers, list) > - if (usage > peer_ctx->value) > - WRITE_ONCE(peer_ctx->value, usage); > + if (peer_ctx != ofp && peer_watermark > peer_ctx->value) > + WRITE_ONCE(peer_ctx->value, peer_watermark); Sorry for letting your previous reply sit unanswered. You made a good point on the peer_watermark = max(usage, local_watermark) being pointless because that's how local_watermark moves to begin with. So what you had before was indeed better. It was just me missing that detail. Could you please go back to your original? Feel free to include: Acked-by: Johannes Weiner