Re: [PATCH] mm/zswap: flush dcache in the compressed decompression path
From: Herbert Xu
Date: Sat Sep 19 2026 - 01:38:48 EST
On Sat, Jul 11, 2026 at 08:25:31AM +0800, Zenghui Yu wrote:
> [+Cc Herbert, in case you missed that]
>
> On 7/11/26 2:43 AM, Yosry Ahmed wrote:
> > On Fri, Jul 10, 2026 at 11:40 AM Joshua Hahn <joshua.hahnjy@xxxxxxxxx> wrote:
> > >
> > > On Fri, 10 Jul 2026 11:22:43 -0700 Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> > >
> > > > 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.
> > > >
> > > > Adding Herbert here.
> > > >
> > > > Doesn't the Crypto API take care of this for the decompression path?
> > > > Maybe in scomp_acomp_comp_decomp()?
> > >
> > > This is what I think too. Actually if you use something like
> > > zstd_decompress() as well, it ends up calling:
> > > acomp_walk_done_dst() --> scatterwalk_done_dst()
> > > --> __scatterwalk_flush_dcache_pages()
> > > --> flush_dcache_page()
> > > over all the pages in the loop.
> > >
> > > Maybe I'm missing a path here that would require us to manually flush
> > > from zswap? But even still, I think that should be handled by the
> > > path that is repsonsible for doing the actual decompression, not
> > > zswap.
> > >
> > > What do you think?
> >
> > Yeah I am hoping Herbert will help us out here.
Sorry for the late response. But yes the Crypto API will definitely
do a flush if the page was written to.
Cheers,
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt