mm/memcontrol.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)
From: Ridong Chen <chenridong@xiaomi.com> 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. --- Changes since v1 [1]: - New patch 1: hold peaks_lock in the peak readers (Sashiko). - Patch 2: floor the peers with max(usage, local_watermark), mirroring peak_show(), and skip the writing fd (Johannes Weiner). [1] https://lore.kernel.org/all/20260730115314.1069089-1-ridong.chen@linux.dev/ Ridong Chen (2): memcg: acquire peaks_lock when reading memory.peak mm, memcg: fix memory.peak reset clobbering other fds' watermark mm/memcontrol.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) -- 2.34.1
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. Sashiko might have found a similar race on the writer side: https://sashiko.dev/#/patchset/20260807090000.1532495-1-ridong.chen@linux.dev
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; -- Best regards Ridong
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
© 2016 - 2026 Red Hat, Inc.