linux-kernel - Re: [PATCH v4] zram: break the strict dependency from lzo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201103212847.GA1631979@google.com>
Date:   Tue, 3 Nov 2020 13:28:47 -0800
From:   Minchan Kim <minchan@...nel.org>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Rui Salvaterra <rsalvaterra@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>, ngupta@...are.org,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] zram: break the strict dependency from lzo

Hi Sergey and Rui,

On Thu, Oct 29, 2020 at 03:59:27AM +0900, Sergey Senozhatsky wrote:
> Cc-ing Andrew
> 
> message-id: 20201028115921.848-1-rsalvaterra@...il.com
> 
> On (20/10/28 11:59), Rui Salvaterra wrote:
> > There's nothing special about zram and lzo. It works just fine without it, so
> > as long as at least one of the other supported compression algorithms is
> > selected.
> > 
> > Suggested-by: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
> > Signed-off-by: Rui Salvaterra <rsalvaterra@...il.com>

Sorry for the late. I am still looking for the time to look into this
patch.

I totally agree with the motivation of Rui. Before that, just a
dumb question.

Can't we just provide choice/endchoice in Kconfig to select default
comp algorithm from admin?

> 
> Minchan, I'm fine with the change.
> 
> Two things from my side:
> 
> 1) The commit message, probably, can be a bit more informative. Something
> like this?
> 
> 	ZRAM always enables CRYPTO_LZO because lzo-rle is the hardcoded
> 	fallback compression algorithm, which means that on systems where
> 	ZRAM always use, for instance, CRYPTO_ZSTD lzo kernel module
> 	becomes unneeded. This patch removes the hardcoded lzo-lre
> 	dependency, instead ZRAM picks the first supported CRYPTO
> 	compression algorithm, should it be ZSTD or LZ4, etc; and only
> 	forcibly enables CRYPTO_LZO (previous behaviour) if none of the
> 	alternative algorithms were selected.
> 
> 
> 2) The ZRAM_AUTOSEL_ALGO allows to deselect CRYPTO_LZO only if
> CRYPTO_LZ4/CRYPTO_LZ4HC/CRYPTO_842/CRYPTO_ZSTD are compiled in (=y).
> If any of the algorithms is selected as a module (=m) then CRYPTO_LZO
> is selected as the default algorithm. Apparently depends on !(CONFIG_FOO)
> means depends on !(CONFIG_FOO=y).
> 
> It appears that the below change fixes it, but it looks a bit ugly.
> 
> ---
> diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
> index 141ce0ebad06..f2fd34de9200 100644
> --- a/drivers/block/zram/Kconfig
> +++ b/drivers/block/zram/Kconfig
> @@ -15,7 +15,7 @@ config ZRAM
>  
>  config ZRAM_AUTOSEL_ALGO
>  	def_bool y
> -	depends on ZRAM && !(CRYPTO_LZ4 || CRYPTO_LZ4HC || CRYPTO_842 || CRYPTO_ZSTD)
> +	depends on ZRAM && !(CRYPTO_LZ4=m || CRYPTO_LZ4HC=m || CRYPTO_842=m || CRYPTO_ZSTD=m || CRYPTO_LZ4=y || CRYPTO_LZ4HC=y || CRYPTO_842=y || CRYPTO_ZSTD=y)
>  	select CRYPTO_LZO
>  
>  config ZRAM_WRITEBACK
> ---
> 
> 	-ss