Re: [PATCH] mm: memcg: stop reclaim when a limit update is superseded

在 2026/7/26 11:42, Andrew Morton 写道:
> On Fri, 24 Jul 2026 10:18:05 +0800 Guopeng Zhang <[email protected]> wrote:
> 
>> From: Guopeng Zhang <[email protected]>
>>
>> kernfs serializes file operations only per open file, so separate open
>> files can update the same memory.high or memory.max file concurrently.
>> Both handlers store the new limit before synchronous reclaim, but
>> continue to use the writer's local target in the reclaim loop. If another
>> writer raises or removes the limit, the first writer can continue
>> reclaiming toward a stale target.
>>
>> For memory.max, this can leave the writer looping indefinitely once
>> reclaim retries are exhausted. The OOM path sees sufficient margin under
>> the current limit and returns true without killing, while the writer
>> still compares usage against its stale target and records another OOM
>> event.
>>
>> Check the current limit at the start of each reclaim iteration and stop
>> if it no longer matches the writer's target.
> 
> Thanks.
> 
>> Fixes: 8c8c383c04f6 ("mm: memcontrol: try harder to set a new memory.high")
> 
> Dec 2019
> 
>> Fixes: b6e6edcfa405 ("mm: memcontrol: reclaim and OOM kill when shrinking memory.max below usage")
> 
> Mar 2016
> 
> Having two Fixes: targets is confusing.  The Fixes: identifies which
> kernel versions should be patched, so how is anyone to figure out
> whether their 2018 kernel actually needs the patch?
> 
> I assume one of the two hunks is for 2019 and the other is for 2016, so
> two separate patches each with a single Fixes: would be more useful.
> 

Thanks, that makes sense.

For similar cases where separate code paths were introduced by different
commits and have different affected-version ranges, I will split the
fixes into separate patches, each with its own Fixes tag.

> That being said, both versions are so ancient that it probably doesn't
> matter.  In fact the bug seems so obscure that I'm not planning on
> adding cc:stable to this anyway.  Maintainers, please advise.
> 
>> Reproducer:
>>
>> Populate a cgroup with anonymous memory and disable swapping. Lower
>> memory.max from one open file, then restore it to "max" through another
>> open file after the new limit becomes visible.
>>
>> Without the patch, the first writer remains blocked and repeatedly
>> increments the OOM event counter. With the patch, it returns normally.
> 
> This is nice info - I'll promote it into the permanent changelog.
> 
> 
> I'll queue the patch for 7.3-rc1 and shall await maintainer input,
> please.
>