Re: [PATCH RFC 08/15] mm/memcg: add folio-based lruvec live helper

On Tue, Aug 4, 2026 at 3:49=E2=80=AFPM Lian Wang <[email protected]> wrot=
e:
>
> From: "Lian Wang (ProcessMission)" <[email protected]>
>
> Hi Kairui,
>
> I am trying to understand the lifetime and accounting guarantee here, and
> would appreciate your guidance. My understanding is that RCU protects the
> lruvec lifetime, but by itself does not stabilize the folio->lruvec
> association across memcg deletion and reparenting.

Hello,

Thanks for the coment and review!

Yes that's correct. And this helper is just a copy of
lruvec_live_lock_irq without the lock.

See https://lore.kernel.org/linux-mm/20260710154318.75388-1-qi.zheng@linux.=
dev/

> Could folio_inc_lru_refs() obtain the child lruvec here, then race with
> __lru_gen_reparent_memcg(), and finally account the generation move to th=
e old
> child after the folio and its counters have moved to the parent? The oppo=
site

Just live the patch above, we are fine as reparent of the
non-hierarchical counters itself will fix it.

> ordering also seems possible: this helper observes css_is_dying() and sel=
ects
> the parent while the folio is still accounted to the child.
>
> Is there another invariant that closes these races? If my understanding i=
s
> correct, it seems the helper guarantees a live object, but not a stable
> binding, and the lockless promotion path may need validation/retry or exp=
licit
> synchronization with reparenting.
>
> If I have misunderstood the intended synchronization here, please feel fr=
ee
> to ignore this concern.

See the example and explanation above, I think there is no issue as
long as the final counter is consistent. Some comment could be
helpful; I will add it in V2, thanks again!