Re: [PATCH v3] crypto: omap-aes: Add support for GCM mode

[Matthijs van Duin]

On 15 September 2015 at 15:28, Lokesh Vutla  wrote:
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -293,6 +293,7 @@ config CRYPTO_DEV_OMAP_AES
> depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP2PLUS
> select CRYPTO_AES
> select CRYPTO_BLKCIPHER
> +   select CRYPTO_AEAD

Is it appropriate that this also selects CRYPTO_AEAD on omap2/omap3,
even though they do not support GCM?



> +#define AES_REG_CTRL_GCM   GENMASK(17, 16)

Instead of adding these definitions one bit at a time, can't we get
the whole list over with at once? This thing supports:

ECB, CBC, and CFB-128 encryption
CTR and F8 encryption with 16/32/64/96/128-bit counter
XEX (disk encryption)
CBC-MAC authentication including the CMAC/OMAC/PMAC subflavors
F9 authentication
GCM and CCM aead
(and raw GHASH, if you happen to have a use for it)
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 7/9] zram: pass zstrm down to decompression path

[Minchan Kim]

On Fri, Sep 18, 2015 at 02:19:22PM +0900, Joonsoo Kim wrote:
> From: Sergey Senozhatsky 
> 
> Introduce zcomp_decompress_begin()/zcomp_decompress_end() as a
> preparation for crypto API-powered zcomp.
> 
> Change zcomp_decompress() signature to require zstrm parameter.
> 
> Unlike zcomp_compress_begin(), zcomp_decompress_begin() may return
> zstrm if currently selected compression backend require zstrm for
> decompression or NULL if it does not.
> 
> Signed-off-by: Sergey Senozhatsky 
> Signed-off-by: Joonsoo Kim 
Acked-by: Minchan Kim 

There is a trivial comment below.

> ---
>  drivers/block/zram/zcomp.c|  3 ++-
>  drivers/block/zram/zcomp.h|  3 ++-
>  drivers/block/zram/zram_drv.c | 20 
>  3 files changed, 20 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> index fc13bf2..3456d5a 100644
> --- a/drivers/block/zram/zcomp.c
> +++ b/drivers/block/zram/zcomp.c
> @@ -336,7 +336,8 @@ int zcomp_compress(struct zcomp *comp, struct zcomp_strm 
> *zstrm,
>   zstrm->private);
>  }
>  
> -int zcomp_decompress(struct zcomp *comp, const unsigned char *src,
> +int zcomp_decompress(struct zcomp *comp, struct zcomp_strm *zstrm,
> + const unsigned char *src,
>   size_t src_len, unsigned char *dst)
>  {
>   return comp->backend->decompress(src, src_len, dst);
> diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
> index 616e013..4c09c01 100644
> --- a/drivers/block/zram/zcomp.h
> +++ b/drivers/block/zram/zcomp.h
> @@ -66,7 +66,8 @@ int zcomp_compress(struct zcomp *comp, struct zcomp_strm 
> *zstrm,
>  struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp);
>  void zcomp_decompress_end(struct zcomp *comp, struct zcomp_strm *zstrm);
>  
> -int zcomp_decompress(struct zcomp *comp, const unsigned char *src,
> +int zcomp_decompress(struct zcomp *comp, struct zcomp_strm *zstrm,
> + const unsigned char *src,
>   size_t src_len, unsigned char *dst);
>  
>  bool zcomp_set_max_streams(struct zcomp *comp, int num_strm);
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 20c41ed..55e09db1 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -560,7 +560,8 @@ static void zram_free_page(struct zram *zram, size_t 
> index)
>   zram_set_obj_size(meta, index, 0);
>  }
>  
> -static int zram_decompress_page(struct zram *zram, char *mem, u32 index)
> +static int zram_decompress_page(struct zram *zram, struct zcomp_strm *zstrm,
> + char *mem, u32 index)
>  {
>   int ret = 0;
>   unsigned char *cmem;
> @@ -582,7 +583,7 @@ static int zram_decompress_page(struct zram *zram, char 
> *mem, u32 index)
>   if (size == PAGE_SIZE)
>   copy_page(mem, cmem);
>   else
> - ret = zcomp_decompress(zram->comp, cmem, size, mem);
> + ret = zcomp_decompress(zram->comp, zstrm, cmem, size, mem);
>   zs_unmap_object(meta->mem_pool, handle);
>   bit_spin_unlock(ZRAM_ACCESS, >table[index].value);
>  
> @@ -602,6 +603,7 @@ static int zram_bvec_read(struct zram *zram, struct 
> bio_vec *bvec,
>   struct page *page;
>   unsigned char *user_mem, *uncmem = NULL;
>   struct zram_meta *meta = zram->meta;
> + struct zcomp_strm *zstrm = NULL;

No need to initialize with NULL.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 6/9] zram: make stream find and release functions static

[Minchan Kim]

On Fri, Sep 18, 2015 at 02:19:21PM +0900, Joonsoo Kim wrote:
> From: Sergey Senozhatsky 
> 
> Hide (make static) zstrm find and release function and introduce
> zcomp_compress_begin()/zcomp_compress_end(). We will have begin
> and end functions around compression (this patch) and decompression
> (next patch). So the work flow is evolving to:
> 
>   zstrm = foo_begin();
>   foo(zstrm);
>   foo_end(zstrm);
> 
> where foo is compress or decompress zcomp functions.
> 
> This patch is a preparation to make crypto API-powered zcomp
> possible. The reasoning is that some crypto compression backends
> require zstrm for decompression.
> 
> Signed-off-by: Sergey Senozhatsky 
> Signed-off-by: Joonsoo Kim 
Acked-by: Minchan Kim 


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] crypto: crc32c-pclmul: use .rodata instead of .rotata

[Nicolas Iooss]

Module crc32c-intel uses a special read-only data section named .rotata.
This section is defined for K_table, and its name seems to be a spelling
mistake for .rodata.

Fixes: 473946e674eb ("crypto: crc32c-pclmul - Shrink K_table to 32-bit words")
Signed-off-by: Nicolas Iooss 
---
 arch/x86/crypto/crc32c-pcl-intel-asm_64.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/crypto/crc32c-pcl-intel-asm_64.S 
b/arch/x86/crypto/crc32c-pcl-intel-asm_64.S
index 225be06edc80..4fe27e074194 100644
--- a/arch/x86/crypto/crc32c-pcl-intel-asm_64.S
+++ b/arch/x86/crypto/crc32c-pcl-intel-asm_64.S
@@ -330,7 +330,7 @@ ENDPROC(crc_pcl)
## PCLMULQDQ tables
## Table is 128 entries x 2 words (8 bytes) each

-.section   .rotata, "a", %progbits
+.section   .rodata, "a", %progbits
 .align 8
 K_table:
.long 0x493c7d27, 0x0001
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 9/9] zram: use crypto decompress_noctx API

[Sergey Senozhatsky]

On (09/18/15 14:19), Joonsoo Kim wrote:
> -/* Never return NULL, may sleep */
> +/* May return NULL, may sleep */
>  struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp)
>  {
> + if (comp->tfm_noctx)
> + return NULL;
> +
>   return zcomp_strm_find(comp);
>  }
>  
> @@ -346,11 +349,18 @@ int zcomp_decompress(struct zcomp *comp, struct 
> zcomp_strm *zstrm,
>  {
>   unsigned int size = PAGE_SIZE;
>  
> + if (!zstrm) {
> + return crypto_comp_decompress_noctx(comp->tfm_noctx,
> + src, src_len, dst, );
> + }

unneeded braces.

-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 8/9] zram: use crypto API for compression

[Sergey Senozhatsky]

On (09/18/15 14:19), Joonsoo Kim wrote:
[..]
> -static struct zcomp_backend *find_backend(const char *compress)
> +static const char *find_backend(const char *compress)
>  {
>   int i = 0;
>   while (backends[i]) {
> - if (sysfs_streq(compress, backends[i]->name))
> + if (sysfs_streq(compress, backends[i]) &&
> + crypto_has_comp(compress, 0, 0))

ok, just for note. zcomp does sysfs_streq(), because sysfs data
usually contain a trailing new line, crypto_has_comp() does strcmp().


>  int zcomp_compress(struct zcomp *comp, struct zcomp_strm *zstrm,
> - const unsigned char *src, size_t *dst_len)
> + const unsigned char *src, unsigned int *dst_len)
>  {
> - return comp->backend->compress(src, zstrm->buffer, dst_len,
> - zstrm->private);
> + *dst_len = PAGE_SIZE << 1;
> +

hm... wouldn't it be better to say crypto api that we have a PAGE_SIZE
buffer instead of PAGE_SIZE << 1, so in case of buffer overrun (or
whatever is the correct term here) it will stop compression earlier
(well, possibly)? zram will drop compressed data larger than PAGE_SIZE
anyway, so if passing a smaller buffer size can save us CPU time then
let's do it.


> + return crypto_comp_compress(zstrm->tfm, src, PAGE_SIZE,
> + zstrm->buffer, dst_len);
>  }
>  
>  int zcomp_decompress(struct zcomp *comp, struct zcomp_strm *zstrm,
>   const unsigned char *src,
> - size_t src_len, unsigned char *dst)
> + unsigned int src_len, unsigned char *dst)
>  {
> - return comp->backend->decompress(src, src_len, dst);
> + unsigned int size = PAGE_SIZE;
> +
> + return crypto_comp_decompress(zstrm->tfm, src, src_len, dst, );

 tab?

>  }
>  
>  void zcomp_destroy(struct zcomp *comp)
> @@ -359,7 +365,7 @@ void zcomp_destroy(struct zcomp *comp)
>  struct zcomp *zcomp_create(const char *compress, int max_strm)
>  {
>   struct zcomp *comp;
> - struct zcomp_backend *backend;
> + const char *backend;

rebase against the current linux-next. this and the next patch do not
apply cleanly. the function was touched recently: '+int error'.


>  
>   backend = find_backend(compress);
>   if (!backend)
> diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
> index 4c09c01..4f9df8e 100644
> --- a/drivers/block/zram/zcomp.h
> +++ b/drivers/block/zram/zcomp.h
> @@ -11,38 +11,22 @@
>  #define _ZCOMP_H_
>  
>  #include 
> +#include 
>  
>  struct zcomp_strm {
> + struct crypto_comp *tfm;
> +
>   /* compression/decompression buffer */
>   void *buffer;
> - /*
> -  * The private data of the compression stream, only compression
> -  * stream backend can touch this (e.g. compression algorithm
> -  * working memory)
> -  */
> - void *private;
> +
>   /* used in multi stream backend, protected by backend strm_lock */
>   struct list_head list;
>  };
>  
> -/* static compression backend */
> -struct zcomp_backend {
> - int (*compress)(const unsigned char *src, unsigned char *dst,
> - size_t *dst_len, void *private);
> -
> - int (*decompress)(const unsigned char *src, size_t src_len,
> - unsigned char *dst);
> -
> - void *(*create)(void);
> - void (*destroy)(void *private);
> -
> - const char *name;
> -};
> -
>  /* dynamic per-device compression frontend */
>  struct zcomp {
>   void *stream;
> - struct zcomp_backend *backend;
> + const char *backend;

^^ what for?

-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 8/9] zram: use crypto API for compression

[Minchan Kim]

Hi Joonsoo,

On Fri, Sep 18, 2015 at 02:19:23PM +0900, Joonsoo Kim wrote:
> Until now, zram uses compression algorithm through direct call
> to core algorithm function, but, it has drawback that we need to add
> compression algorithm manually to zram if needed. Without this work,
> we cannot utilize various compression algorithms in the system.
> Moreover, to add new compression algorithm, we need to know how to use it
> and this is somewhat time-consuming.
> 
> When I tested new algorithms such as zlib, these problems make me hard
> to test them. To prevent these problem in the future, I think that
> using crypto API for compression is better approach and this patch
> implements it.
> 
> The reason we need to support vairous compression algorithms is that
> zram's performance is highly depend on workload and compression algorithm
> and architecture. Every compression algorithm has it's own strong point.
> For example, zlib is the best for compression ratio, but, it's
> (de)compression speed is rather slow. Against my expectation, in my kernel
> build test with zram swap, in low-memory condition on x86, zlib shows best
> performance than others. In this case, I guess that compression ratio is
> the most important factor. Unlike this situation, on ARM, maybe fast
> (de)compression speed is the most important because it's computation speed
> is slower than x86.
> 
> We can't expect what algorithm is the best fit for one's system, because
> it needs too complex calculation. We need to test it in case by case and
> easy to use new compression algorithm by this patch will help
> that situation.
> 
> There is one problem that crypto API requires tfm object to (de)compress
> something and zram abstract it on zstrm which is very limited resource.
> If number of zstrm is set to low and is contended, zram's performace could
> be down-graded due to this change. But, following patch support to use
> crypto decompress_noctx API and would restore the performance as is.
> 
> Signed-off-by: Joonsoo Kim 
> ---
>  drivers/block/zram/Kconfig |  8 +++
>  drivers/block/zram/Makefile|  4 +---
>  drivers/block/zram/zcomp.c | 54 
> +++---
>  drivers/block/zram/zcomp.h | 30 ++-
>  drivers/block/zram/zcomp_lz4.c | 47 
>  drivers/block/zram/zcomp_lz4.h | 17 -
>  drivers/block/zram/zcomp_lzo.c | 47 
>  drivers/block/zram/zcomp_lzo.h | 17 -
>  drivers/block/zram/zram_drv.c  |  6 ++---
>  9 files changed, 44 insertions(+), 186 deletions(-)
>  delete mode 100644 drivers/block/zram/zcomp_lz4.c
>  delete mode 100644 drivers/block/zram/zcomp_lz4.h
>  delete mode 100644 drivers/block/zram/zcomp_lzo.c
>  delete mode 100644 drivers/block/zram/zcomp_lzo.h
> 
> diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
> index 386ba3d..7619bed 100644
> --- a/drivers/block/zram/Kconfig
> +++ b/drivers/block/zram/Kconfig
> @@ -1,8 +1,7 @@
>  config ZRAM
>   tristate "Compressed RAM block device support"
>   depends on BLOCK && SYSFS && ZSMALLOC
> - select LZO_COMPRESS
> - select LZO_DECOMPRESS
> + select CRYPTO_LZO
>   default n
>   help
> Creates virtual block devices called /dev/zramX (X = 0, 1, ...).
> @@ -18,9 +17,8 @@ config ZRAM
>  config ZRAM_LZ4_COMPRESS
>   bool "Enable LZ4 algorithm support"
>   depends on ZRAM
> - select LZ4_COMPRESS
> - select LZ4_DECOMPRESS
> + select CRYPTO_LZ4

It is out of my expectation.

When I heard crypto support for zRAM first, I imagined zram user can
use any crypto compressor algorithm easily if system has the algorithm.
IOW, I expect zRAM shouldn't bind CONFIG_CRYPTO_ALGONAME statically
except the default one(ie, CONFIG_CRYPTO_LZO) like zswap and It seems
you did in eariler version.

You seem to have a trouble to adapt crypto to current comp_algorithm
because crypto doesn't export any API to enumerate algorithm name
while zram should export supporting algorithm name via comp_algorithm
and I heard crypto maintainer doesn't want to export it. Instead,
user can use /proc/crypto to know what kinds of compressor system
can support.

Hmm,
At the first glance, I was about to say "let's sort it out with
futher patches" but I changed my mind. ;-).

We should sort it out before you are adding zlib support(ie, please
include zlib support patch with number data in this patchset). Otherwise,
we should add new hard-wired stuff for zlib like lzo, lz4 to
comp_algorithm and will depreate soon.

My idea is ABI change of comp_algorithm. Namely, let's deprecate it
and guide to use /proc/crypto to show available compressor.
Someday, we removes backends string array finally.

Welcome to any ideas.

>   default n
>   help
> This option enables LZ4 compression algorithm support. Compression
> -   algorithm can be changed using `comp_algorithm' device 

Re: [PATCH v3 9/9] zram: use crypto decompress_noctx API

[Minchan Kim]

On Fri, Sep 18, 2015 at 02:19:24PM +0900, Joonsoo Kim wrote:
> Crypto subsystem now supports decompress_noctx API that requires
> special tfm_noctx. This tfm can be shared by multiple concurrent
> decompress user because this API doesn't rely on this tfm object
> except to fetch decompress function pointer.
> 
> Until changing to use crypto API, zram doesn't require any zstrm
> on decompress so decompress is parallelized unlimitedly. But, previous
> patch make zram to use crypto API and this requires one zstrm on every
> decompress users so, in some zstrm contended situations, zram's
> performance would be degraded.
> 
> This patch makes zram use decompress_noctx API and restore zram's
> performance as the time that zram doesn't use crypto API.
> 
> Following is zram's read performance number.
> 
> * iozone -t 4 -R -r 16K -s 60M -I +Z -i 0 -i 1
> * max_stream is set to 1
> * Output is in Kbytes/sec
> 
> zram-base vs zram-crypto vs zram-crypto-noctx
> 
> Read  10411701.88 6426911.62  9423894.38
> Re-read   10017386.62 6428218.88  1163.50
> 
> Signed-off-by: Joonsoo Kim 
> ---
>  drivers/block/zram/zcomp.c | 24 +++-
>  drivers/block/zram/zcomp.h |  1 +
>  2 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> index c2ed7c8..a020200 100644
> --- a/drivers/block/zram/zcomp.c
> +++ b/drivers/block/zram/zcomp.c
> @@ -319,9 +319,12 @@ void zcomp_compress_end(struct zcomp *comp, struct 
> zcomp_strm *zstrm)
>   zcomp_strm_release(comp, zstrm);
>  }
>  
> -/* Never return NULL, may sleep */
> +/* May return NULL, may sleep */
>  struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp)
>  {
> + if (comp->tfm_noctx)
> + return NULL;

Hmm,, I understand why returns NULL but it seems to be awkward to use NULL
to express meaningful semantic and following functions relies on.
If I have a time, I will think over.

> +
>   return zcomp_strm_find(comp);
>  }
>  
> @@ -346,11 +349,18 @@ int zcomp_decompress(struct zcomp *comp, struct 
> zcomp_strm *zstrm,
>  {
>   unsigned int size = PAGE_SIZE;
>  
> + if (!zstrm) {
> + return crypto_comp_decompress_noctx(comp->tfm_noctx,
> + src, src_len, dst, );
> + }
> +
>   return crypto_comp_decompress(zstrm->tfm, src, src_len, dst, );
>  }
>  
>  void zcomp_destroy(struct zcomp *comp)
>  {
> + if (comp->tfm_noctx)
> + crypto_free_comp_noctx(comp->tfm_noctx);
>   comp->destroy(comp);
>   kfree(comp);
>  }
> @@ -366,6 +376,7 @@ struct zcomp *zcomp_create(const char *compress, int 
> max_strm)
>  {
>   struct zcomp *comp;
>   const char *backend;
> + struct crypto_comp *tfm;
>  
>   backend = find_backend(compress);
>   if (!backend)
> @@ -384,5 +395,16 @@ struct zcomp *zcomp_create(const char *compress, int 
> max_strm)
>   kfree(comp);
>   return ERR_PTR(-ENOMEM);
>   }
> +
> + /*
> +  * Prepare to use crypto decompress_noctx API. One tfm is required
> +  * to initialize crypto algorithm properly and fetch corresponding
> +  * function pointer. But, it is sharable for multiple concurrent
> +  * decompress users.
> +  */

Please comment out that this API will return NULL if the compressor doesn't
support noctx mode.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/9] zram: introduce crypto decompress noctx API and use it on zram

[Minchan Kim]

On Fri, Sep 18, 2015 at 02:19:15PM +0900, Joonsoo Kim wrote:
> This patchset makes zram to use crypto API in order to support
> more compression algorithm.
> 
> The reason we need to support vairous compression algorithms is that
> zram's performance is highly depend on workload and compression algorithm
> and architecture. Every compression algorithm has it's own strong point.
> For example, zlib is the best for compression ratio, but, it's
> (de)compression speed is rather slow. Against my expectation, in my kernel
> build test with zram swap, in low-memory condition on x86, zlib shows best
> performance than others. In this case, I guess that compression ratio is
> the most important factor. Unlike this situation, on ARM, maybe fast
> (de)compression speed is the most important because it's computation speed
> is slower than x86.

Fair enough. lzo and lz4 cannot cover all of workloads so surely, there are
workloads other compressor algorithm can win. As well, we could support
H/W compressor with crypto support so I think crypto is a way to go.

One thing I have a concern is I don't want to bind some of compressor
algorithm to zram statically. User can see what kinds of crypto compressor
support in his system via /proc/crypto and use it dynamically.
I hope zram supports it.

> 
> Anyway, there is a concern from Sergey to use crypto API in zram. Current
> crypto API has a limitation that always require tfm object to (de)compress
> something because some of (de)compression function requires scratch buffer
> embedded on tfm even if some of (de)compression function doesn't
> require it. Due to above reason, using crypto API rather than calling

Nice catch from Sergey!

> compression library directly causes more memory footprint and this is
> why zram doesn't use crypto API before.
> 
> In this patchset, crypto compress noctx API is introduced to reduce memory
> footprint caused by maintaining multiple tfm and zram uses it. Before
> noctx API, zram's performace is down-graded if tfm is insufficient. But,
> after applying noctx API, performace is restored.
> 
> This addresses Sergey's concern perfectly and provides possibility to use
> various compression algorithm in zram.
> 
> Following is zram's read performance number.
> 
> * iozone -t 4 -R -r 16K -s 60M -I +Z -i 0 -i 1
> * max_stream is set to 1
> * Output is in Kbytes/sec
> 
> zram-base vs zram-crypto vs zram-crypto-noctx
> 
> Read  10411701.88 6426911.62  9423894.38 
> Re-read   10017386.62 6428218.88  1163.50 

Another patch and number we need to merge this patchset is zlib support
patchset and number you had experiement.

> 
> Thanks.
> 
> Joonsoo Kim (7):
>   crypto: introduce decompression API that can be called via sharable
> tfm object
>   crypto/lzo: support decompress_noctx
>   crypyo/lz4: support decompress_noctx
>   crypto/lz4hc: support decompress_noctx
>   crypto/842: support decompress_noctx
>   zram: use crypto API for compression
>   zram: use crypto decompress_noctx API
> 
> Sergey Senozhatsky (2):
>   zram: make stream find and release functions static
>   zram: pass zstrm down to decompression path
> 
>  crypto/842.c   |   9 +++-
>  crypto/compress.c  |  36 +++
>  crypto/crypto_null.c   |   3 +-
>  crypto/deflate.c   |   3 +-
>  crypto/lz4.c   |   9 +++-
>  crypto/lz4hc.c |   9 +++-
>  crypto/lzo.c   |   9 +++-
>  drivers/block/zram/Kconfig |   8 ++--
>  drivers/block/zram/Makefile|   4 +-
>  drivers/block/zram/zcomp.c | 102 
> +++--
>  drivers/block/zram/zcomp.h |  42 +++--
>  drivers/block/zram/zcomp_lz4.c |  47 ---
>  drivers/block/zram/zcomp_lz4.h |  17 ---
>  drivers/block/zram/zcomp_lzo.c |  47 ---
>  drivers/block/zram/zcomp_lzo.h |  17 ---
>  drivers/block/zram/zram_drv.c  |  32 +
>  include/linux/crypto.h |  20 
>  17 files changed, 211 insertions(+), 203 deletions(-)
>  delete mode 100644 drivers/block/zram/zcomp_lz4.c
>  delete mode 100644 drivers/block/zram/zcomp_lz4.h
>  delete mode 100644 drivers/block/zram/zcomp_lzo.c
>  delete mode 100644 drivers/block/zram/zcomp_lzo.h
> 
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/9] crypto: introduce decompression API that can be called via sharable tfm object

[Sergey Senozhatsky]

On (09/18/15 14:19), Joonsoo Kim wrote:
[..]
> @@ -61,7 +61,8 @@ static struct crypto_alg alg = {
>   .cra_module = THIS_MODULE,
>   .cra_u  = { .compress = {
>   .coa_compress   = crypto842_compress,
> - .coa_decompress = crypto842_decompress } }
> + .coa_decompress = crypto842_decompress,
> + .coa_decompress_noctx   = NULL } }
>  };
>  
>  static int __init crypto842_mod_init(void)
> diff --git a/crypto/compress.c b/crypto/compress.c
> index c33f076..abb36a8 100644
> --- a/crypto/compress.c
> +++ b/crypto/compress.c
> @@ -33,12 +33,21 @@ static int crypto_decompress(struct crypto_tfm *tfm,
>  dlen);
>  }
>  
> +static int crypto_decompress_noctx(struct crypto_tfm *tfm,
> + const u8 *src, unsigned int slen,
> + u8 *dst, unsigned int *dlen)
> +{
> + return tfm->__crt_alg->cra_compress.coa_decompress_noctx(src, slen,
> + dst, dlen);
> +}


hm... well... sorry, if irrelevant.
if the algorithm can have a _noctx() decompression function, does it
automatically guarantee that this algorithm never dereferences a passed
`struct crypto_tfm *tfm' pointer in its decompress function? in other words,
can we simply pass that `shared tfm pointer' to the existing decompress
function instead of defining new symbols, new callbacks, etc.?

cot_decompress_noctx()  ==  cot_decompress(shared_ftm) ?

just a thought.

[..]
> +struct crypto_comp *crypto_alloc_comp_noctx(const char *alg_name,
> + u32 type, u32 mask)
> +{
> + struct crypto_comp *comp;
> + struct crypto_tfm *tfm;
> + struct compress_tfm *ops;
> +
> + comp = crypto_alloc_comp(alg_name, type, mask);
> + if (IS_ERR(comp))
> + return comp;
> +
> + tfm = crypto_comp_tfm(comp);
> + if (!tfm->__crt_alg->cra_compress.coa_decompress_noctx) {
> + crypto_free_comp(comp);
> + return ERR_PTR(-EINVAL);

-ENOMEM?

-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html