Re: [PATCH] mm: mglru: splice all generations when reparenting a memcg

[Baolin Wang <baolin.wang@linux.alibaba.com>]

On 11/12/26 2:13 AM, Kairui Song wrote:
> On Wed, Nov 11, 2026 at 8:10 AM Shakeel Butt <shakeel.butt@linux.dev> wrote:
>>
>> Noah reported list_del corruption on single-node hosts running 7.2.11,
>> which already has commit bf4ade7dbd76 ("memcg: keep folio's objcg same
>> as its node"). The bad pointer is an MGLRU list head in a freed
>> mem_cgroup_per_node:
>>
>>    slab mem_cgroup_per_node start ff31bfa36a3c9e00 pointer offset 528 size 1920
>>    list_del corruption. next->prev should be ffacf881ccc70e08, but was ff31bfa36a3ca010. (next=ff31bfa36a3ca010)
>>
>> When a memcg goes offline, __lru_gen_reparent_memcg() moves its MGLRU
>> lists to the parent. It moves only the generations (gens) from min_seq
>> to max_seq, and it puts each list at the same index in the parent.
>>
>> A folio's gen in folio->flags can be ahead of the list it is on. In the
>> parent, the same index can stand for an older gen, so the folio's gen
>> can end up older than its list. Once the parent's min_seq passes that
>> gen, sort_folio() puts the folio on the list for max_seq + 1, where it
>> stays until the next aging.
>>
>> If the parent goes offline before that aging, the folio is not moved to
>> the grandparent. It stays on the parent's list after the parent is
>> freed, and the next list_del() on it touches freed memory. This needs
>> two cgroups on one branch to go offline one after the other, such as a
>> container and then its pod.
>>
>> The parent always has MAX_NR_GENS gens at this point, so every index is
>> valid in it. Move all MAX_NR_GENS lists, not only the gens from min_seq
>> to max_seq.
>>
>> A reproducer that drives these steps through the lru_gen debugfs file
>> gets a KASAN use-after-free on the freed mem_cgroup_per_node without
>> this patch, and no report with it.
>>
>> Fixes: f304652609ea ("mm: vmscan: prepare for reparenting MGLRU folios")
>> Reported-by: Noah Feldt <noah@feldt.systems>
>> Closes: https://lore.kernel.org/all/20261110132853.71228-1-noah@feldt.systems/
>> Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
>> Cc: <stable@vger.kernel.org>
>> ---
>>   mm/vmscan.c | 12 +++++++++---
>>   1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index 6a1af9b92349..902616a3b755 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -4751,19 +4751,25 @@ void max_lru_gen_memcg(struct mem_cgroup *memcg, int nid)
>>    * The same generation has different meanings in the parent and child memcg,
>>    * so this compromise method will cause the LRU inversion problem. But as the
>>    * system runs, this problem will be fixed automatically.
>> + *
>> + * Move all MAX_NR_GENS lists, not only the gens from min_seq to max_seq.
>> + * An earlier reparenting can leave a folio whose gen is older than the list
>> + * it is on. Once min_seq passes that gen, sort_folio() puts the folio on the
>> + * list for max_seq + 1, where it stays until the next aging. If that list
> 
> "sort_folio() puts the folio on the list for max_seq + 1" seems not
> very accurate as MAX_NR_GENS - MIN_NR_GENS == 2, could be any stale
> gen outside [min_seq, max_seq], right?

+1. The comments are not easy to understand. IIUC, the problem is that 
the folio's gen can fall outside lruvec->[min_seq, max_seq], potentially 
causing the folio to be left behind on a memcg that is about to be freed.

But, yes, the fix is correct. So,
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>