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

From: Harry Yoo

Date: Thu Nov 20 2025 - 22:17:07 EST


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
section, and technically calling rcu_read_unlock() right after acquiring
the spinlock is fine?

--
Cheers,
Harry / Hyeonggon

> ```
>
> In the memcg_reparent_objcgs(memcg) function:
> ```
> spin_lock(&lruvec->lru_lock);
> spin_lock(&lruvec_parent->lru_lock);
> /* Transfer folios from the lruvec list to the parent's. */
> spin_unlock(&lruvec_parent->lru_lock);
> spin_unlock(&lruvec->lru_lock);
> ```
>
> After acquiring the lruvec lock, it is necessary to verify whether
> the folio has been reparented. If reparenting has occurred, the new
> lruvec lock must be reacquired. During the LRU folio reparenting
> process, the lruvec lock will also be acquired (this will be
> implemented in a subsequent patch). Therefore, folio_memcg() remains
> unchanged while the lruvec lock is held.
>
> Given that lruvec_memcg(lruvec) is always equal to folio_memcg(folio)
> after the lruvec lock is acquired, the lruvec_memcg_debug() check is
> redundant. Hence, it is removed.
>
> This patch serves as a preparation for the reparenting of LRU folios.
>
> Signed-off-by: Muchun Song <songmuchun@xxxxxxxxxxxxx>
> Signed-off-by: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>
> ---