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

[Baoquan He <baoquan.he@linux.dev>]

On 09/13/26 at 12:48am, Andrew Morton wrote:
> On Sun, 13 Sep 2026 14:30:31 +0800 Baoquan He <hebaoquan@kylinos.cn> wrote:
> 
> > 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.
> 
> I'm struggling to understand the userspace-visible runtime effects of this.
> 
> I see that reclaim will prematurely abort, but is this a once-off thing
> which will resolve on the next reclaim attempt, or will the reclaim
> failure persist for a significant period?

Not a one-off, and not permanent either: it lasts the whole swapoff.

Assume I have two swap disks. zswap is enabled. By default 20% of RAM is
the zswap upper limit. So now if I swapoff /dev/vdb, at the same time
reclaimer call shrinker to writeback, -EEXIST makes shrink_memcg_cb()
return LRU_STOP, which ends the shrink pass right there. get_swap_device()
returns NULL for an entry whose device is gone, so every such entry still
on the zswap LRU stops a pass where it stands. The pool gets almost nothing
written back for the length of the swapoff.

# swapon
NAME     TYPE      SIZE USED PRIO
/dev/vdb partition   4G   0B   -1
/dev/vdc partition   2G   0B   -1

The entry is rotated before writeback, so later passes get past it. It is
a throughput collapse, not a deadlock.

static enum lru_status shrink_memcg_cb(struct list_head *item, struct list_lru_one *l,
                                       void *arg)
{
	......
	list_move_tail(item, &l->list);
	......
	writeback_result = zswap_writeback_entry(entry, swpentry);
	......
}

I can't reproduce it now. And I forget how I met this, just did too many
tiems of testing and code change. this probably comes from reading the
code. So this may be a logic bug that rarely happens rather than a easily
seen regression.

Thanks
Baoquan