Re: [PATCH] mm: zswap: return -ENOENT when the swap device is gone

[Baoquan He]

On 09/14/26 at 09:16pm, Andrew Morton wrote:
> On Mon, 14 Sep 2026 14:31:39 +0800 Baoquan He <baoquan.he@xxxxxxxxx> wrote:
> 
> > > 
> > > >  	si = get_swap_device(swpentry);
> > > >  	if (!si)
> > > > -		return -EEXIST;
> > > > +		return -ENOENT;
> > > 
> > > mm-new has changed.  I made this
> > 
> > Thanks. Does it need a v2? or just use ther version you tuned.
> 
> I fixed it up while fixing the rejects, I hope.  Below.

Thanks. The last paragraph of patch log need be adjusted as shown at bottom.

> 
> > By the way, which mm branch is suggested to take as a base for mm
> > patches posting? I usually take mm-unstable branch, seems it's changed
> > to mm-new now?
> 
> mm-new is a front-end to mm-unstable.  The only difference is that
> mm-new isn't included in linux-next.  New material goes into mm-new and
> if it hasn't caused any disasters for a few days I'll move it into
> mm-unstable and hence linux-next.
> 
> Ordinarily there isn't much material in mm-new.  At this moment
> mm-unstable has 405 patches and mm-new has another 96.  That 96 is
> unusually large because people have been sending huge patchsets today.
> 
> So mm-new is the best target for my merging pleasure but it is surely a
> pain for ongoing development - it's changing at a great rate.  Those
> 500 patches landed in 15 days.
> 
> I suggest a reasonable process is, approximately, to develop against
> mainline (or mm-stable if there's anything in it) until you think the
> code is ready for mm.git.  Then rebase/retest against mm-new and send
> it out.  But keep an eye on what's happening in mm.git so that the
> rebasing doesn't cause nasty surprises.

It's very clear to me now, thanks a lot for the detailed explanation.

> 
> 
> 
> From: Baoquan He <hebaoquan@xxxxxxxxxx>
> Subject: mm: zswap: return -ENOENT when the swap device is gone
> Date: Sun, 13 Sep 2026 14:30:31 +0800
> 
> zswap_writeback_entry() returns -EEXIST when get_swap_device() finds no
> device.  -EEXIST is the shrinker's "page already in swap cache" signal,
> which makes zswap_shrinker_scan() stop shrinking entirely.  A NULL
> get_swap_device() instead means the device is being swapped off, so the
> entry is simply stale.
> 
> Return -ENOENT so the shrinker skips the stale entry and keeps scanning.
> Independent of xswap; affects all swap devices.
                ~~~~~
The term xswap sneaks into log while it's an ongoing feature. The last
paragraph should be:

===
Return -ENOENT so the shrinker skips the stale entry and keeps scanning.
It affects all swap devices.
===

> 
> Link: https://lore.kernel.org/20260913063031.1689420-1-hebaoquan@xxxxxxxxxx
> Signed-off-by: Baoquan He <hebaoquan@xxxxxxxxxx>
> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> Acked-by: Nhat Pham <nphamcs@xxxxxxxxx>
> Cc: Chengming Zhou <chengming.zhou@xxxxxxxxx>
> Cc: Chris Li <chrisl@xxxxxxxxxx>
> Cc: Johannes Weiner <hannes@xxxxxxxxxxx>
> Cc: Kairui Song <kasong@xxxxxxxxxxx>
> ---
> 
>  mm/zswap.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/mm/zswap.c~mm-zswap-return-enoent-when-the-swap-device-is-gone
> +++ a/mm/zswap.c
> @@ -1016,7 +1016,7 @@ static int zswap_writeback_entry(struct
>  	/* try to allocate swap cache folio */
>  	si = get_swap_device(swpentry);
>  	if (IS_ERR_OR_NULL(si))
> -		return -EEXIST;
> +		return -ENOENT;
>  
>  	mpol = get_task_policy(current);
>  	folio = swap_cache_alloc_folio(swpentry, GFP_KERNEL, BIT(0), NULL, mpol,
> _
>