linux-kernel - Re: [External] Re: [RFC PATCH v3 02/12] mm: memcontrol: introduce compact_lock_page_lruvec

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: <CAMZfGtXEJv1mU5CHZV3H7Qkkmq0mEugQpOpDM7Q=K-Sr1L3ydQ@mail.gmail.com>
Date:   Wed, 26 May 2021 10:49:08 +0800
From:   Muchun Song <songmuchun@...edance.com>
To:     Roman Gushchin <guro@...com>
Cc:     Johannes Weiner <hannes@...xchg.org>,
        Michal Hocko <mhocko@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Shakeel Butt <shakeelb@...gle.com>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        Xiongchun duan <duanxiongchun@...edance.com>,
        fam.zheng@...edance.com, "Singh, Balbir" <bsingharora@...il.com>,
        Yang Shi <shy828301@...il.com>,
        Alex Shi <alex.shi@...ux.alibaba.com>
Subject: Re: [External] Re: [RFC PATCH v3 02/12] mm: memcontrol: introduce compact_lock_page_lruvec_irqsave

On Wed, May 26, 2021 at 1:21 AM Roman Gushchin <guro@...com> wrote:
>
> On Wed, Apr 21, 2021 at 03:00:49PM +0800, Muchun Song wrote:
> > If we reuse the objcg APIs to charge LRU pages, the page_memcg()
> > can be changed when the LRU pages reparented. In this case, we need
> > to acquire the new lruvec lock.
> >
> >     lruvec = mem_cgroup_page_lruvec(page);
> >
> >     // 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 page_memcg() detect whether we need to reacquire the new
> > lruvec lock. So compact_lock_irqsave() is not suitable for us.
> > Similar to lock_page_lruvec_irqsave(), introduce
> > compact_lock_page_lruvec_irqsave() to acquire the lruvec lock in
> > the compaction routine.
> >
> > Signed-off-by: Muchun Song <songmuchun@...edance.com>
>
> Acked-by: Roman Gushchin <guro@...com>

Thanks.

>
> > ---
> >  mm/compaction.c | 27 ++++++++++++++++++++++++---
> >  1 file changed, 24 insertions(+), 3 deletions(-)
> >
> > diff --git a/mm/compaction.c b/mm/compaction.c
> > index 1c500e697c88..082293587cc6 100644
> > --- a/mm/compaction.c
> > +++ b/mm/compaction.c
> > @@ -511,6 +511,29 @@ static bool compact_lock_irqsave(spinlock_t *lock, unsigned long *flags,
> >       return true;
> >  }
> >
> > +static struct lruvec *
> > +compact_lock_page_lruvec_irqsave(struct page *page, unsigned long *flags,
> > +                              struct compact_control *cc)
>
> Maybe compact_lock_page_irqsave() to make it more similar to
> compact_lock_irqsafe()? But it's up to you.

I like a more brief name, compact_lock_page_irqsave is a good and
brief name. Thanks.

>
> Thanks!