linux-kernel - Re: [PATCH 4/7] zram: align zcomp interface to crypto comp API

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160527043137.GD2322@bbox>
Date:	Fri, 27 May 2016 13:31:37 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	<linux-kernel@...r.kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [PATCH 4/7] zram: align zcomp interface to crypto comp API

On Wed, May 25, 2016 at 11:30:03PM +0900, Sergey Senozhatsky wrote:
> A cosmetic change: use the same datatypes as crypto API does.
> 
> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
> Cc: Minchan Kim <minchan@...nel.org>
> Cc: Joonsoo Kim <iamjoonsoo.kim@....com>
> ---
>  drivers/block/zram/zcomp.c    | 5 ++---
>  drivers/block/zram/zcomp.h    | 5 ++---
>  drivers/block/zram/zram_drv.c | 2 +-
>  3 files changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> index 6e16fa2..79b30d7 100644
> --- a/drivers/block/zram/zcomp.c
> +++ b/drivers/block/zram/zcomp.c
> @@ -103,7 +103,7 @@ void zcomp_stream_put(struct zcomp *comp)
>  }
>  
>  int zcomp_compress(struct zcomp_strm *zstrm,
> -		const unsigned char *src, unsigned int *dst_len)
> +		const u8 *src, unsigned int *dst_len)

Nitpick:

The zcomp doesn't need to depend on implementation(i.e., crypto) so
zcomp_compress should pass void * for src and dst.

I'm not strong aginst changing u8 but your description makes me
think about that. 


>  {
>  	/*
>  	 * Our dst memory (zstrm->buffer) is always `2 * PAGE_SIZE' sized
> @@ -127,8 +127,7 @@ int zcomp_compress(struct zcomp_strm *zstrm,
>  }
>  
>  int zcomp_decompress(struct zcomp_strm *zstrm,
> -		const unsigned char *src,
> -		size_t src_len, unsigned char *dst)
> +		const u8 *src, unsigned int src_len, u8 *dst)
>  {
>  	unsigned int dst_len = PAGE_SIZE;
>  
> diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
> index 3fb9dc4..dcc0951 100644
> --- a/drivers/block/zram/zcomp.h
> +++ b/drivers/block/zram/zcomp.h
> @@ -54,11 +54,10 @@ struct zcomp_strm *zcomp_stream_get(struct zcomp *comp);
>  void zcomp_stream_put(struct zcomp *comp);
>  
>  int zcomp_compress(struct zcomp_strm *zstrm,
> -		const unsigned char *src, unsigned int *dst_len);
> +		const u8 *src, unsigned int *dst_len);
>  
>  int zcomp_decompress(struct zcomp_strm *zstrm,
> -		const unsigned char *src,
> -		size_t src_len, unsigned char *dst);
> +		const u8 *src, unsigned int src_len, u8 *dst);
>  
>  bool zcomp_set_max_streams(struct zcomp *comp, int num_strm);
>  #endif /* _ZCOMP_H_ */
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 99c8be7..65d1403 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -563,7 +563,7 @@ static int zram_decompress_page(struct zram *zram, char *mem, u32 index)
>  	unsigned char *cmem;
>  	struct zram_meta *meta = zram->meta;
>  	unsigned long handle;
> -	size_t size;
> +	unsigned int size;
>  
>  	bit_spin_lock(ZRAM_ACCESS, &meta->table[index].value);
>  	handle = meta->table[index].handle;
> -- 
> 2.8.3.394.g3916adf
>