Re: [PATCH v2 23/28] mm: memcontrol: prepare for reparenting LRU pages for lruvec lock

[Qi Zheng]

On 12/20/25 10:03 AM, Shakeel Butt wrote:
> On Wed, Dec 17, 2025 at 03:27:47PM +0800, Qi Zheng wrote:
> > @@ -1232,14 +1221,20 @@ struct lruvec *folio_lruvec_lock(struct folio *folio)
> >    * - folio frozen (refcount of 0)
> >    *
> >    * Return: The lruvec this folio is on with its lock held and interrupts
> > - * disabled.
> > + * disabled and rcu read lock held.
> >    */
> >   struct lruvec *folio_lruvec_lock_irq(struct folio *folio)
> >   {
> > -	struct lruvec *lruvec = folio_lruvec(folio);
> > +	struct lruvec *lruvec;
> >   
> > +	rcu_read_lock();
> > +retry:
> > +	lruvec = folio_lruvec(folio);
> >   	spin_lock_irq(&lruvec->lru_lock);
> > -	lruvec_memcg_debug(lruvec, folio);
> > +	if (unlikely(lruvec_memcg(lruvec) != folio_memcg(folio))) {
> > +		spin_unlock_irq(&lruvec->lru_lock);
> > +		goto retry;
> > +	}
>
> So after this patch, all folio_lruvec_lock_irq() calls should be paired
> with lruvec_unlock_irq() but lru_note_cost_refault() is calling
> folio_lruvec_lock_irq() without the paired lruvec_unlock_irq(). It is
> using lru_note_cost_unlock_irq() for unlocking lru lock and thus rcu
> read unlock is missed.

Indeed. Will fix in the next version.

> Beside fixing this, I would suggest to add __acquire()/__release() tags
> for both lru lock and rcu for all these functions.

OK, will do.


Thanks,
Qi

>