linux-kernel - Re: [PATCH v1 23/26] mm: vmscan: prepare for reparenting MGLRU folios

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJj2-QHu3u1RQpkBw8uV9P+-xop+bJvxt+s-ZB_cj=u6ia+tbg@mail.gmail.com>
Date: Mon, 1 Dec 2025 15:50:05 -0600
From: Yuanchu Xie <yuanchu@...gle.com>
To: Qi Zheng <qi.zheng@...ux.dev>
Cc: Harry Yoo <harry.yoo@...cle.com>, hannes@...xchg.org, hughd@...gle.com, 
	mhocko@...e.com, roman.gushchin@...ux.dev, shakeel.butt@...ux.dev, 
	muchun.song@...ux.dev, david@...hat.com, lorenzo.stoakes@...cle.com, 
	ziy@...dia.com, imran.f.khan@...cle.com, kamalesh.babulal@...cle.com, 
	axelrasmussen@...gle.com, weixugc@...gle.com, akpm@...ux-foundation.org, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, cgroups@...r.kernel.org, 
	Qi Zheng <zhengqi.arch@...edance.com>
Subject: Re: [PATCH v1 23/26] mm: vmscan: prepare for reparenting MGLRU folios

On Mon, Dec 1, 2025 at 9:41 AM Qi Zheng <qi.zheng@...ux.dev> wrote:
> > Warning 1) Here we increment max_seq but we skip updating mm_state->seq.
> > (try_to_inc_max_seq() iterates the mm list and update mm_state->seq after
> > an iteration, but since we directly call inc_max_seq(), we don't update it)
> >
> > When mm_state->seq is more than one generation behind walk->seq, a warning is
> > triggered in iterate_mm_list():
> >
> >          VM_WARN_ON_ONCE(mm_state->seq + 1 < walk->max_seq);
>
> The mm_state->seq is just to record the completion of a full traversal
> of mm_list. If we simply delete this warning, it may cause this judgment
> in iterate_mm_list to become invalid:
>
>          if (walk->seq <= mm_state->seq)
>                 goto done;
>
> So it seems we can manually increase mm_state->seq during reparenting to
> avoid this warning.
Agreed, don't get rid of the warning as this check is supposed to make
stale walkers exit early.

>
> However, we cannot directly call iterate_mm_list_nowalk() because we do
> not want to reset mm_state->head and mm_state->tail to NULL. Otherwise,
> we wouldn't be able to continue iterating over the mm_list.
>

>From the original posting:
> Of course, the same generation has different meanings in the parent and
> child memcg, this will cause confusion in the hot and cold information of
> folios. But other than that, this method is simple enough, the lru size
> is correct, and there is no need to consider some concurrency issues (such
> as lru_gen_del_folio()).
One way to solve this is to map generations based on
lrugen->timestamp, but of course this runs into the reading
folio->flags issue you described. I think the current method is a good
compromise, but the splicing of generations doesn't much make semantic
sense. It would be good to leave a comment somewhere in
__lru_gen_reparent_memcg to note this weirdness.