Re: [PATCH] mm/zswap: validate dlen and normalize comp_ret on compression success

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 23 Oct 2026 20:04:26 +0000 Suseendran Bhaskaran <suseendranb@google.com> wrote:

> > Wht you forgot to tell us (please never forget this) is the
> > userspace-visible runtime effects of the bug.  Autobot says:
> >
> > : The userspace-visible effects are limited to corrected zswap
> > : statistics and a new warning for invalid compressor results.
> > :
> > : When compression succeeds but produces exactly PAGE_SIZE bytes, and
> > : zswap writeback is disabled, the page is rejected as before. However,
> > : reject_compress_poor now increments instead of reject_compress_fail.
> > : This makes the debugfs statistics distinguish incompressible pages
> > : from actual compressor failures more accurately.
> > :
> > : A compressor which reports success with a zero or oversized output
> > : length will now trigger WARN_ON_ONCE(). Previously, zswap handled
> > : these results without a warning. On systems with panic_on_warn
> > : enabled, this could cause a kernel panic.
> > :
> > : There is no intended change to which pages zswap accepts, rejects
> > : or stores uncompressed, nor to normal application behavior.
> > :
> > : I think these runtime effects should be described more prominently
> > : in the changelog, particularly the new warning.
> 
> Apologies for missing the userspace-visible runtime impact in the commit
> description. I will make sure to always include this going forward.
> Autobot is spot-on here. I would be happy to send a v2 with an updated
> commit message that clearly documents these runtime effects and
> behavioral changes.

I'm mainly interested in answering "should we backport this into
-stable kernels?".  A small debugfs accounting error is probably a
"no", but a WARN is "yes".  Is that real?  Can current kernels truly
emit WARNs due to this issue?

If so then yup, please send along a new changelog.  Or a v2 with a new
changelog.