Re: [PATCH v4 3/4] zram: validate parameters in each backend's setup_params

On (26/08/03 20:20), haoqin huang wrote:
> On Thu, Jul 30, 2026 at 3:24 PM Sergey Senozhatsky
> <[email protected]> wrote:
> > > diff --git a/drivers/block/zram/backend_lz4hc.c b/drivers/block/zram/backend_lz4hc.c
> > > index f6a336acfe20..5d551d165213 100644
> > > --- a/drivers/block/zram/backend_lz4hc.c
> > > +++ b/drivers/block/zram/backend_lz4hc.c
> > > @@ -20,6 +20,11 @@ static int lz4hc_setup_params(struct zcomp_params *params)
> > >  {
> > >       if (params->level == ZCOMP_PARAM_NOT_SET)
> > >               params->level = LZ4HC_DEFAULT_CLEVEL;
> > > +     else if (params->level < LZ4HC_MIN_CLEVEL ||
> > > +              params->level > LZ4HC_MAX_CLEVEL) {
> > > +             pr_err("lz4hc: invalid compression level %d\n", params->level);
> > > +             return -EINVAL;
> > > +     }
> >
> > So...  lib/lz4/lz4hc_compress.c supports levels 1 and 2.  However,
> > LZ4HC_MIN_CLEVEL is set to 3, but clearly the compression library
> > supports levels lower than LZ4HC_MIN_CLEVEL.  In fact, LZ4HC_MIN_CLEVEL
> > is never used in the lz4 code.  Maybe here we need to just hardcode
> > "< 1" and put a comment:
> >
> 
> My bad, completely missed that LZ4HC_MIN_CLEVEL is advisory and the
> library actually accepts 1-2.  Will hardcode < 1 in v5.

No worries, that LZ4HC_MIN_CLEVEL thing is difficult to spot.

> Btw, would it make sense to fix LZ4HC_MIN_CLEVEL to 1 in the lz4
> header as a separate cleanup?  It seems misleading as-is.

I'm afraid we cannot do that.  f2fs uses LZ4HC_MIN_CLEVEL, I assume
compression level is stored per-inode?  So if we change LZ4HC_MIN_CLEVEL
then newer f2fs will start accepting compression levels that older kernels
don't support.  Cc-ed Jaegeuk and Chao just for visibility.