Re: [PATCH 1/2] crypto: return -ENOSPC on compression destination overflow
From: Yosry Ahmed
Date: Thu Oct 22 2026 - 18:20:01 EST
On Thu, Oct 22, 2026 at 8:34 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> On Thu, Oct 22, 2026 at 1:14 AM Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Wed, Oct 21, 2026 at 08:56:25PM +0000, Suseendran Bhaskaran wrote:
> > > In the acomp/scomp compression interface, callers pass a bounded
> > > destination buffer and rely on the return code to distinguish a
> > > destination buffer overflow (incompressible input) from genuine
> > > compressor failures (such as invalid parameters, uninitialized state, or
> > > hardware errors).
> > >
> > > While the multi-segment streaming path in zstd_compress(),
> > > crypto/deflate.c, and lib/842/842_compress.c returns -ENOSPC when the
> > > destination buffer runs out of space, the single-buffer path
> > > zstd_compress_one() (taken when input and output are contiguous single
> > > pages, such as in zswap) as well as lz4, lz4hc, lzo, and lzo-rle return
> > > -EINVAL instead of -ENOSPC on destination buffer overflow.
> > >
> > > For users such as zswap, which reduced its per-CPU compression buffer to
> > > a single page in commit 0b1bf60c324a ("mm/zswap: reduce the size of the
> > > compression buffer to a single page"), incompressible pages typically
> > > overflow the PAGE_SIZE destination buffer due to compressor header/token
> > > overhead. Because these compressors return -EINVAL rather than -ENOSPC,
> > > zswap cannot distinguish a destination buffer overflow from a compressor
> > > failure, causing broken debugfs error accounting (reject_compress_fail
> > > vs. reject_compress_poor) or masking real compressor errors.
> > >
> > > Update zstd_compress_one(), lz4, lz4hc, lzo, and lzo-rle to return
> > > -ENOSPC when the compressed output overflows the destination buffer,
> > > matching the streaming path in zstd_compress(), deflate, and 842.
> > >
> > > Fixes: f5ad93ffb541 ("crypto: zstd - convert to acomp")
> > > Signed-off-by: Suseendran Bhaskaran <suseendranb@xxxxxxxxxx>
> > > ---
> > > crypto/lz4.c | 2 +-
> > > crypto/lz4hc.c | 2 +-
> > > crypto/lzo-rle.c | 2 +-
> > > crypto/lzo.c | 2 +-
> > > crypto/zstd.c | 5 ++++-
> > > 5 files changed, 8 insertions(+), 5 deletions(-)
> >
> > I can take this patch through the cryptodev tree. Is that OK with
> > you Yosry?
>
> Thanks Herbert. I think we should wait to see how patch #2 turns out.
> If I understand correctly, as of now patch #2 keys off -ENOSPC to make
> a behavioral change in zswap, so the zswap patch would need to land
> *after* this patch. Unless you want to fast track this to Linus right
> away?
Patch 2 will be re-sent separately, so please feel free to take this
patch as-is. Thanks!