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

[Usama Arif]

On 06/09/2026 10:19, Yosry Ahmed wrote:
> 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? :)



Hello!

Below is what the patch looks like in my tree now. It can be sent independently of
the PMD swap series. Yosry if you are happy with it, will send it on the list