[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKEwX=O4MCgM=CrnWWNaan0g1xmAWeFxXM8=OpKuZM4v3ajDFw@mail.gmail.com>
Date: Thu, 17 Apr 2025 10:39:05 -0700
From: Nhat Pham <nphamcs@...il.com>
To: Muchun Song <songmuchun@...edance.com>
Cc: hannes@...xchg.org, mhocko@...nel.org, roman.gushchin@...ux.dev,
shakeel.butt@...ux.dev, muchun.song@...ux.dev, akpm@...ux-foundation.org,
david@...morbit.com, zhengqi.arch@...edance.com, yosry.ahmed@...ux.dev,
chengming.zhou@...ux.dev, linux-kernel@...r.kernel.org,
cgroups@...r.kernel.org, linux-mm@...ck.org, hamzamahfooz@...ux.microsoft.com,
apais@...ux.microsoft.com
Subject: Re: [PATCH RFC 21/28] mm: zswap: prevent lruvec release in zswap_folio_swapin()
On Mon, Apr 14, 2025 at 7:47 PM Muchun Song <songmuchun@...edance.com> wrote:
>
> In the near future, a folio will no longer pin its corresponding
> memory cgroup. So an lruvec returned by folio_lruvec() could be
> released without the rcu read lock or a reference to its memory
> cgroup.
>
> In the current patch, the rcu read lock is employed to safeguard
> against the release of the lruvec in zswap_folio_swapin().
>
> This serves as a preparatory measure for the reparenting of the
> LRU pages.
>
> Signed-off-by: Muchun Song <songmuchun@...edance.com>
No objections from my end. AFAICT, wrapping this in rcu should not
break things, and we're in the slow path (disk swapping) anyway, so
should not be a problem.
Anyway:
Acked-by: Nhat Pham <nphamcs@...il.com>
Powered by blists - more mailing lists