Re: [PATCH] mm/zswap: flush dcache in the compressed decompression path

[Nhat Pham]

On Fri, Jul 10, 2026 at 1:28 AM Song Hu <husong@xxxxxxxxxx> wrote:
>
> Both branches of zswap_decompress() write the destination folio through a
> kernel mapping: the incompressible branch via kmap_local_folio() and the
> compressed branch via the crypto scatterwalk. Yet only the incompressible
> branch calls flush_dcache_folio(); the compressed branch was missed. On
> aliasing D-cache architectures this can leave stale cache lines visible to
> userland after a zswap load.
>
> zram flushes in the same situation (zram_bio_read()). Hoist a single
> flush_dcache_folio() out of the incompressible branch so both paths are
> covered.
>
> Fixes: e2c3b6b21c77 ("mm: zswap: use SG list decompression APIs from zsmalloc")

I'll leave other maintainers take a closer look at this in terms of correctness.

I'll just ask one question: was the bug (if real) introduced by this
patch, or has it been problematic before this?

Seems like this patch changes the input end of decompression, but does
not actually touch the output (folio) end?

I managed to trace this all the way to 1ec3b5f ("mm/zswap: move to use
crypto_acomp API for hardware acceleration" +Barry), which introduces
the SG/crypto API, but not entirely sure if it was broken here
already? Or maybe even before this?

Yosry and Barry, WDYT?