linux-kernel - Re: [PATCH v4 02/11] mm: memcontrol: introduce compact_folio_lruvec_lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yo35ITjnDUrvLpfC@FVFYT0MHHV2J.googleapis.com>
Date:   Wed, 25 May 2022 17:38:41 +0800
From:   Muchun Song <songmuchun@...edance.com>
To:     Johannes Weiner <hannes@...xchg.org>
Cc:     mhocko@...nel.org, roman.gushchin@...ux.dev, shakeelb@...gle.com,
        cgroups@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, duanxiongchun@...edance.com,
        longman@...hat.com
Subject: Re: [PATCH v4 02/11] mm: memcontrol: introduce
 compact_folio_lruvec_lock_irqsave

On Tue, May 24, 2022 at 03:22:55PM -0400, Johannes Weiner wrote:
> On Tue, May 24, 2022 at 02:05:42PM +0800, Muchun Song wrote:
> > If we reuse the objcg APIs to charge LRU pages, the folio_memcg()
> > can be changed when the LRU pages reparented. In this case, we need
> > to acquire the new lruvec lock.
> > 
> >     lruvec = folio_lruvec(folio);
> > 
> >     // The page is reparented.
> > 
> >     compact_lock_irqsave(&lruvec->lru_lock, &flags, cc);
> > 
> >     // Acquired the wrong lruvec lock and need to retry.
> > 
> > But compact_lock_irqsave() only take lruvec lock as the parameter,
> > we cannot aware this change. If it can take the page as parameter
> > to acquire the lruvec lock. When the page memcg is changed, we can
> > use the folio_memcg() detect whether we need to reacquire the new
> > lruvec lock. So compact_lock_irqsave() is not suitable for us.
> > Similar to folio_lruvec_lock_irqsave(), introduce
> > compact_folio_lruvec_lock_irqsave() to acquire the lruvec lock in
> > the compaction routine.
> > 
> > Signed-off-by: Muchun Song <songmuchun@...edance.com>
> 
> This looks generally good to me.
> 
> It did raise the question how deferencing lruvec is safe before the
> lock is acquired when reparenting can race. The answer is in the next
> patch when you add the rcu_read_lock(). Since the patches aren't big,
> it would probably be better to merge them.
>

Will do in v5.
 
> > @@ -509,6 +509,29 @@ static bool compact_lock_irqsave(spinlock_t *lock, unsigned long *flags,
> >  	return true;
> >  }
> >  
> > +static struct lruvec *
> > +compact_folio_lruvec_lock_irqsave(struct folio *folio, unsigned long *flags,
> > +				  struct compact_control *cc)
> > +{
> > +	struct lruvec *lruvec;
> > +
> > +	lruvec = folio_lruvec(folio);
> > +
> > +	/* Track if the lock is contended in async mode */
> > +	if (cc->mode == MIGRATE_ASYNC && !cc->contended) {
> > +		if (spin_trylock_irqsave(&lruvec->lru_lock, *flags))
> > +			goto out;
> > +
> > +		cc->contended = true;
> > +	}
> > +
> > +	spin_lock_irqsave(&lruvec->lru_lock, *flags);
> 
> Can you implement this on top of the existing one?
> 
> 	lruvec = folio_lruvec(folio);
> 	compact_lock_irqsave(&lruvec->lru_lock, flags);
> 	lruvec_memcg_debug(lruvec, folio);
> 	return lruvec;
> 

I'll do a try. Thanks for your suggestions.