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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130731134750.GA4523@gmail.com>
Date:	Wed, 31 Jul 2013 22:47:50 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	Piotr Sarna <p.sarna@...tner.samsung.com>
Cc:	gregkh@...uxfoundation.org, ngupta@...are.org,
	linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
	b.zolnierkie@...sung.com, Kyungmin Park <kyungmin.park@...sung.com>
Subject: Re: [PATCH 1/2] staging: zram: add Crypto API support

Hello,

On Tue, Jul 30, 2013 at 02:30:48PM +0200, Piotr Sarna wrote:
> Current version of zram does not allow any substitution of a default
> compression algorithm. Therefore, I decided to change the existing
> implementation of page compression by adding Crypto API compability.
> 
> All direct calls to lzo1x compression/decompression methods are now
> replaced by calls consistent with Crypto. Also, I removed "workmem"
> field from struct zram_meta, as it was there for lzo1x purposes only
> and is no longer needed. Finally, I added a set of functions required
> by Crypto API to work properly.
> 
> In order to substitute the default algorithm (lzo), change the value
> of zram.compressor module parameter to a proper name (e.g. lz4).

Your patch [1,2/2] are totally same patch I made for using in-house only.
Why I made it for in-house only is that Greg doesn't want to merge any
new features before zram promotion is done.
I understand him totally because I will do same thing as if I were
maintainer.

I tried zram promotion several long time ago but unfortunately, failed.
Sine then, I have been busy by other stuffs.

http://comments.gmane.org/gmane.linux.kernel.mm/90264

The reason to prevent zram promotion is only zsmalloc while Jens
already acked zram part because zsmalloc was used for zcache,
zram and zswap at that time and they have different requirements
for zsmalloc. But recently, zsmalloc is used for only zram so I guess
we could put zsmalloc with zram in driver/block. Of course, we should
discuss it with akpm.

Okay. I think it's good time to promote zram again and I will retry
soon.

Thanks.

> 
> Signed-off-by: Piotr Sarna <p.sarna@...tner.samsung.com>
> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@...sung.com>

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ