Re: [PATCH v1 21/26] mm: memcontrol: prepare for reparenting LRU pages for lruvec lock

[Qi Zheng]

On 11/21/25 11:15 AM, Harry Yoo wrote:
> On Tue, Oct 28, 2025 at 09:58:34PM +0800, Qi Zheng wrote:
> > From: Muchun Song <songmuchun@xxxxxxxxxxxxx>
> >
> > The following diagram illustrates how to ensure the safety of the folio
> > lruvec lock when LRU folios undergo reparenting.
> >
> > In the folio_lruvec_lock(folio) function:
> > ```
> >      rcu_read_lock();
> > retry:
> >      lruvec = folio_lruvec(folio);
> >      /* There is a possibility of folio reparenting at this point. */
> >      spin_lock(&lruvec->lru_lock);
> >      if (unlikely(lruvec_memcg(lruvec) != folio_memcg(folio))) {
> >          /*
> >           * The wrong lruvec lock was acquired, and a retry is required.
> >           * This is because the folio resides on the parent memcg lruvec
> >           * list.
> >           */
> >          spin_unlock(&lruvec->lru_lock);
> >          goto retry;
> >      }
> >
> >      /* Reaching here indicates that folio_memcg() is stable. */
>
> Does that mean we call rcu_read_unlock() in lruvec_unlock() instead of
> in folio_lruvec_lock() only to avoid false warnings inside the critical

Right.

> section, and technically calling rcu_read_unlock() right after acquiring
> the spinlock is fine?

Right.

>