Re: [PATCH v2 03/15] zram: lz4hc: reset the dictionary stream once, not per page

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Medium] zram: high-order memory allocation using kzalloc in
  lz4hc_create() [1]
--

commit 2f51683dc7418bdcd0730283cb7003d8754fcd5f
Author: Michal Wilczynski <m.wilczynski@samsung.com>

zram: lz4hc: reset the dictionary stream once, not per page

This commit moves the LZ4_resetStreamHC() call for dictionary-backed
streams from lz4hc_compress() to lz4hc_create() so that the stream state is
only reset once at creation time rather than on every compressed page.

> diff --git a/drivers/block/zram/backend_lz4hc.c b/drivers/block/zram/backend_lz4hc.c
> index d8aa01bb258fe..06286c805cf7c 100644
> --- a/drivers/block/zram/backend_lz4hc.c
> +++ b/drivers/block/zram/backend_lz4hc.c
> @@ -72,6 +72,7 @@ static int lz4hc_create(struct zcomp_params *params, struct zcomp_ctx *ctx)
>  		zctx->cstrm = kzalloc_obj(*zctx->cstrm);
>  		if (!zctx->cstrm)
>  			goto error;
> +		LZ4_resetStreamHC(zctx->cstrm, params->level);
>  	}

[Severity: Medium]
This problem wasn't introduced by this patch, but should zctx->cstrm be
allocated with vmalloc() or kvzalloc() instead of kzalloc_obj() [1]?

LZ4_streamHC_t is 262,192 bytes (LZ4_STREAMHCSIZE), so kzalloc_obj()
requests an order-7 physically contiguous allocation.  Unlike the
non-dictionary path right above, which uses vmalloc(LZ4HC_MEM_COMPRESS),
this allocation can easily fail under normal memory fragmentation during
zram initialization or CPU hotplug.

[1] https://sashiko.dev/#/bug/linux-78ebc045-5e81-4f0b-985e-99483d454b25

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106-lz4-vendor-upstream-v2-0-ee04c3f0d7dc@samsung.com?part=3