Re: [PATCH 1/1] mm/zswap: enable static key after runtime pool recovery

[Yosry Ahmed]

On Sat, Sep 5, 2026 at 4:09 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Sat,  5 Sep 2026 20:50:28 +0800 Longlong Xia <xialonglong2025@xxxxxxx> wrote:
>
> > From: Longlong Xia <xialonglong@xxxxxxxxxx>
> >
> > When CONFIG_ZSWAP_DEFAULT_ON is disabled, zswap_setup() can complete
> > without a pool after a failed initial pool creation. A later compressor
> > parameter update can create and publish a pool, but does not enable
> > zswap_ever_enabled.
> >
> > If users then enable zswap, zswap_store() intercepts swapout while
> > zswap_load() still returns -ENOENT without consulting the xarray. The
> > swapin path therefore reads a stale backing swap slot because the store
> > skipped writing it.
>
> That sounds bad.  I'll leave it to reviewers to suggest whether this is
> a sufficient description of the runtime effects, and to decide whether
> a backport is appropriate.  Please.

Yes this needs a stable backport AFAICT.

A more high-level description would be:

If zswap is enabled by default at boot and pool creation fails, then a
pool is later created by updating the compressor, data written to
zswap is corrupted on swapin.

>
> > Enable the static key after a successful compressor and pool update. Do
> > this outside zswap_pools_lock because static key updates may sleep.
> >
> > Verified with fault injection on a stock kernel (compressor builtin,
> > CONFIG_ZSWAP_DEFAULT_ON=n):
> >
> >   1. Boot with zswap.enabled=1; pool creation fails, init completes
> >      pool-less (static key off).
> >   2. Echo an available compressor name to zswap.compressor; a pool is
> >      recovered but the key stays off.
> >   3. Enable zswap.
> >   4. madvise(MADV_PAGEOUT) a pattern-verified 512 MiB region, then
> >      fault it back in and verify.
> >
> > Step 4 reads back 131072/131072 zeroed pages (zswpin=0, zswpout=131072)
> > without this patch; all pages intact (zswpin=131072) with it.
>
> And thanks.  Sashiko might have found another issue in this zswap code:
>         https://sashiko.dev/#/patchset/20260905125101.2970456-1-xialonglong2025@xxxxxxx

Hmm I think this might be fixed by Alexandre's patch (in Usama's
series): https://lore.kernel.org/linux-mm/20260818131202.494754-6-usama.arif@xxxxxxxxx/.

Instead of always returning -EINVAL for large folios we only do so if
they are actually in zswap. Usama/Alexandre, assuming I got this
right, can I interest you in sending the zswap bits of that patch as a
standalone fix? :)