On Fri, Dec 2, 2022 at 4:50 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 2 Dec 2022 16:38:12 -0800 Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > On Fri, Dec 2, 2022 at 4:35 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Fri, 2 Dec 2022 16:26:05 -0800 Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > > > > Andrew, does this need to be picked up by stable branches? > > > > > > Does it? The changelog doesn't have a clear description of the > > > user-visible effects of the flaw, which is the guiding light for a > > > backport? > > > > > > > > > > There are 2 example scenarios in the changelog that misbehave without > > this fix, cases where the protection of a memcg that is the target of > > reclaim is not ignored as it should be. > > Yes. I found them quite unclear. How would someone who is > experiencing a particualr runtime issue be able to recognize whether > this patch might address that issue? > When we are doing memcg reclaim, the intended behavior is that we ignore any protection (memory.min, memory.low) of the target memcg (but not its children). Ever since the patch pointed to by the "Fixes" tag, we actually read a stale value for the target memcg protection when deciding whether to skip the memcg or not because it is protected. If the stale value happens to be high enough, we don't reclaim from the target memcg. Essentially, in some cases we may falsely skip reclaiming from the target memcg of reclaim because we read a stale protection value from last time we reclaimed from it.
