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

[Yosry Ahmed]

On Fri, Oct 23, 2026 at 4:21 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, 23 Oct 2026 20:04:26 +0000 Suseendran Bhaskaran <suseendranb@xxxxxxxxxx> 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?

No need for a stable backport, it's just debugfs accounting, and the
new WARN is just hardening.

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