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

Qi Zheng
2025-11-21T08:02:14Z

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@bytedance.com>
>>
>> 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.

>