[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cf8e2dba-83dd-4ad3-b98d-2e463ea569d9@linux.dev>
Date: Fri, 18 Apr 2025 10:36:03 +0800
From: Chengming Zhou <chengming.zhou@...ux.dev>
To: Muchun Song <songmuchun@...edance.com>, 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, nphamcs@...il.com
Cc: 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 2025/4/15 10:45, Muchun Song 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>
It should be rare to race with folio reparenting process, so
it seems ok not to "reparent" this counter "nr_disk_swapins".
Reviewed-by: Chengming Zhou <chengming.zhou@...ux.dev>
Thanks.
> ---
> mm/zswap.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/mm/zswap.c b/mm/zswap.c
> index 204fb59da33c..4a41c2371f3d 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -752,8 +752,10 @@ void zswap_folio_swapin(struct folio *folio)
> struct lruvec *lruvec;
>
> if (folio) {
> + rcu_read_lock();
> lruvec = folio_lruvec(folio);
> atomic_long_inc(&lruvec->zswap_lruvec_state.nr_disk_swapins);
> + rcu_read_unlock();
> }
> }
>
Powered by blists - more mailing lists