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

On Thu, Jul 30, 2026 at 3:24=E2=80=AFPM Sergey Senozhatsky
<[email protected]> wrote:
>
> On (26/07/30 14:01), Haoqin Huang wrote:
> [..]
> >  static int deflate_setup_params(struct zcomp_params *params)
> >  {
> > +     if (params->dict_sz) {
> > +             pr_err("deflate: dictionary is not supported\n");
> > +             return -EOPNOTSUPP;
> > +     }
> >       if (params->level =3D=3D ZCOMP_PARAM_NOT_SET)
> >               params->level =3D Z_DEFAULT_COMPRESSION;
> > +     else if (params->level < Z_DEFAULT_COMPRESSION ||
> > +              params->level > Z_BEST_COMPRESSION) {
> > +             pr_err("deflate: invalid compression level %d\n", params-=
>level);
> > +             return -EINVAL;
> > +     }
> >       if (params->deflate.winbits =3D=3D ZCOMP_PARAM_NOT_SET)
> >               params->deflate.winbits =3D DEFLATE_DEF_WINBITS;
>
> This will conflict with winbits validation change that we landed
> yesterday.  Can I trouble you with a rebase request (either on top
> of linux-next, when winbits patch hits it, or on top of Andrew's mm
> tree)?
>

Sorry for the delayed response, I'll rebase on linux-next for v5.

> [..]
> > diff --git a/drivers/block/zram/backend_lz4hc.c b/drivers/block/zram/ba=
ckend_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 *p=
arams)
> >  {
> >       if (params->level =3D=3D ZCOMP_PARAM_NOT_SET)
> >               params->level =3D LZ4HC_DEFAULT_CLEVEL;
> > +     else if (params->level < LZ4HC_MIN_CLEVEL ||
> > +              params->level > LZ4HC_MAX_CLEVEL) {
> > +             pr_err("lz4hc: invalid compression level %d\n", params->l=
evel);
> > +             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.

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.

>       } else if (params->level < 1 || params->level > LZ4HC_MAX_CLEVEL) {
>               /*
>                * Not LZ4HC_MIN_CLEVEL: that constant is advisory, and
>                * LZ4HC_compress_generic() only clamps levels below 1.
>                * Levels 1-2 are valid.
>                */
>               pr_err("lz4hc: invalid compression level %d\n", params->lev=
el);
>               return -EINVAL;
>       }
>
> [..]
> > diff --git a/drivers/block/zram/backend_zstd.c b/drivers/block/zram/bac=
kend_zstd.c
> > index 2584f47c9b3c..4d19d6089f13 100644
> > --- a/drivers/block/zram/backend_zstd.c
> > +++ b/drivers/block/zram/backend_zstd.c
> > @@ -60,6 +60,11 @@ static int zstd_setup_params(struct zcomp_params *pa=
rams)
> >       params->drv_data =3D zp;
> >       if (params->level =3D=3D ZCOMP_PARAM_NOT_SET)
> >               params->level =3D zstd_default_clevel();
> > +     else if (params->level < zstd_min_clevel() ||
> > +              params->level > zstd_max_clevel()) {
> > +             pr_err("zstd: invalid compression level %d\n", params->le=
vel);
> > +             goto error;
>
> Should we also remove "zstd_release_params(params);" from here?
> Same reason as with zstd_create().

Right, same reasoning as patch 1, zstd_setup_params() shouldn't do
its own teardown since zcomp_init() already calls release_params() on
failure.  Will merge this into patch 1 in v5.