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

[Kairui Song]

On Tue, Aug 4, 2026 at 3:49 PM Lian Wang <lianux.mm@xxxxxxxxx> wrote:
>
> From: "Lian Wang (ProcessMission)" <lianux.mm@xxxxxxxxx>
>
> 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@xxxxxxxxx/

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

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 selects
> the parent while the folio is still accounted to the child.
>
> Is there another invariant that closes these races? If my understanding is
> correct, it seems the helper guarantees a live object, but not a stable
> binding, and the lockless promotion path may need validation/retry or explicit
> synchronization with reparenting.
>
> If I have misunderstood the intended synchronization here, please feel free
> 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!