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

[Zenghui Yu]

[+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.
>