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

[Ridong Chen <ridong.chen@linux.dev>]

On 8/10/2026 10:58 AM, Ridong Chen wrote:
> 
> 
> On 8/8/2026 4:22 AM, Andrew Morton wrote:
>> On Fri,  7 Aug 2026 16:59:58 +0800 Ridong <ridong.chen@linux.dev> 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/20260807090000.1532495-1-ridong.chen@linux.dev
> 
> Yes, that's the writer side that patch 2 fixes;
> 

Hello everyone,

I would appreciate a review of this series. Should any feedback come up, I will 
update both the patch and the cover letter accordingly.

-- 
Best regards
Ridong