Re: [PATCH v2 0/2] mm, memcg: fix memory.peak reset clobbering other fds' watermark

Ridong Chen <[email protected]>
Newsgroups org.kvack.linux-mm,org.kernel.vger.cgroups,org.kernel.vger.linux-kernel
Message-ID <[email protected]>

On 8/8/2026 4:22 AM, Andrew Morton wrote:
> On Fri,  7 Aug 2026 16:59:58 +0800 Ridong <[email protected]> wrote:
> 
>> Two fixes for the per-fd memory.peak / memory.swap.peak handlers added in
>> c6f53ed8f213. Each open fd reads back max(its own value, the shared
>> local_watermark), and both bugs live in that scheme.
> 
> Thanks.
> 
> We're missing the preferred description of the worst-case
> userspace-visible effects of the bug.  It appears they're quite minor
> so I'll assume this series is a post-7.2 thing.
> 

Agreed, post-7.2 is fine and neither is stable material.

Worst case for both: a reader of memory.peak (or memory.swap.peak)
gets a value lower than the true peak, so a tool that sizes or bills a
cgroup by peak usage under-reports it.

- Patch 1 (reader side, take peaks_lock in peak_show): a reader that
   races an unrelated reset briefly gets the low value. Transient.

- Patch 2 (writer side, peak_write reset): a reset on one fd stores
   the current usage into the other watchers instead of the old
   watermark, dragging every other fd's peak down.

I'll spell this out in both changelogs in v2.

> Sashiko might have found a similar race on the writer side:
> 	https://sashiko.dev/#/patchset/[email protected]

Yes, that's the writer side that patch 2 fixes;

-- 
Best regards
Ridong
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.