Re: [PATCH v1 3/4] Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver

2015-08-20 Thread Vinod Koul 
On Thu, Aug 20, 2015 at 12:31:44PM +0530, Rameshwar Sahu wrote:
 Hi Vinod,
 
 On Thu, Aug 20, 2015 at 11:18 AM, Vinod Koul vinod.k...@intel.com wrote:
  On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
  + nents = sg_nents(req-src);
  + sg_count = dma_map_sg(dev, req-src, nents, DMA_TO_DEVICE);
  + if (!sg_count) {
  + dev_err(dev, Failed to map src sg);
  + return -ENOMEM;
  mapping error shouldn't be no mem error
 Okay, I guess then -EIO will be fine here??

yes better

-- 
~Vinod
--
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 v2 8/8] zram: use decompress_noctx

2015-08-20 Thread Joonsoo Kim 
Crypto subsystem supports noctx API which doesn't require tfm.
To get tfm in zram, we need zstrm and it is limited resource.
If we uses noctx API, we don't need to get zstrm so that
we get much better performance when zstrm is insufficient.

This patch restores zram's performance to the time that zram
doesn't use crypto subsystem.

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

Read10411701.88 6426911.62  9423894.38
Re-read 10017386.62 6428218.88  1163.50

Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
---
 drivers/block/zram/zcomp.c| 28 +++-
 drivers/block/zram/zcomp.h|  9 -
 drivers/block/zram/zram_drv.c |  9 +
 3 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index d2734f2..86b0c9b 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -291,8 +291,12 @@ bool zcomp_set_max_streams(struct zcomp *comp, int 
num_strm)
return comp-set_max_streams(comp, num_strm);
 }
 
-struct zcomp_strm *zcomp_strm_find(struct zcomp *comp)
+struct zcomp_strm *zcomp_strm_find(struct zcomp *comp, bool decomp)
 {
+   /* We don't need decompression context so zstrm neither */
+   if (decomp  test_bit(ZCOMP_DECOMPRESS_NOCTX, comp-flags))
+   return NULL;
+
return comp-strm_find(comp);
 }
 
@@ -307,6 +311,11 @@ int zcomp_compress(struct zcomp *comp, struct zcomp_strm 
*zstrm,
 {
*dst_len = PAGE_SIZE  1;
 
+   if (!zstrm) {
+   return crypto_comp_compress_noctx(comp-alg, src, PAGE_SIZE,
+   dst, dst_len);
+   }
+
return crypto_comp_compress(zstrm-tfm, src, PAGE_SIZE, dst, dst_len);
 }
 
@@ -316,12 +325,18 @@ int zcomp_decompress(struct zcomp *comp, struct 
zcomp_strm *zstrm,
 {
unsigned int size = PAGE_SIZE;
 
+   if (!zstrm) {
+   return crypto_comp_decompress_noctx(comp-alg, src, src_len,
+   dst, size);
+   }
+
return crypto_comp_decompress(zstrm-tfm, src, src_len, dst, size);
 }
 
 void zcomp_destroy(struct zcomp *comp)
 {
comp-destroy(comp);
+   crypto_put_comp(comp-alg);
kfree(comp);
 }
 
@@ -344,12 +359,23 @@ struct zcomp *zcomp_create(const char *compress, int 
max_strm)
return ERR_PTR(-ENOMEM);
 
comp-name = compress;
+   comp-alg = crypto_get_comp(compress, 0, 0);
+   if (!comp-alg) {
+   kfree(comp);
+   return ERR_PTR(-EINVAL);
+   }
+
+   if (crypto_has_compress_noctx(comp-alg))
+   set_bit(ZCOMP_COMPRESS_NOCTX, comp-flags);
+   if (crypto_has_decompress_noctx(comp-alg))
+   set_bit(ZCOMP_DECOMPRESS_NOCTX, comp-flags);
 
if (max_strm  1)
zcomp_strm_multi_create(comp, max_strm);
else
zcomp_strm_single_create(comp);
if (!comp-stream) {
+   crypto_put_comp(comp-alg);
kfree(comp);
return ERR_PTR(-ENOMEM);
}
diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
index c47db4d..6c137c8 100644
--- a/drivers/block/zram/zcomp.h
+++ b/drivers/block/zram/zcomp.h
@@ -13,6 +13,11 @@
 #include linux/crypto.h
 #include linux/mutex.h
 
+enum {
+   ZCOMP_COMPRESS_NOCTX,
+   ZCOMP_DECOMPRESS_NOCTX,
+};
+
 struct zcomp_strm {
struct crypto_comp *tfm;
 
@@ -27,6 +32,8 @@ struct zcomp_strm {
 struct zcomp {
void *stream;
const char *name;
+   struct crypto_alg *alg;
+   unsigned long flags;
 
struct zcomp_strm *(*strm_find)(struct zcomp *comp);
void (*strm_release)(struct zcomp *comp, struct zcomp_strm *zstrm);
@@ -39,7 +46,7 @@ ssize_t zcomp_available_show(const char *comp, char *buf);
 struct zcomp *zcomp_create(const char *comp, int max_strm);
 void zcomp_destroy(struct zcomp *comp);
 
-struct zcomp_strm *zcomp_strm_find(struct zcomp *comp);
+struct zcomp_strm *zcomp_strm_find(struct zcomp *comp, bool decomp);
 void zcomp_strm_release(struct zcomp *comp, struct zcomp_strm *zstrm);
 
 int zcomp_compress(struct zcomp *comp, struct zcomp_strm *zstrm,
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index b3044d3..8283bd3 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -623,7 +623,7 @@ static int zram_bvec_read(struct zram *zram, struct bio_vec 
*bvec,
/* Use  a temporary buffer to decompress the page */
uncmem = kmalloc(PAGE_SIZE, GFP_NOIO);
 
-   zstrm = zcomp_strm_find(zram-comp);
+   zstrm = zcomp_strm_find(zram-comp, true);
user_mem = kmap_atomic(page);
if (!is_partial_io(bvec))
uncmem =

[PATCH v2 7/8] zram: use crypto API for compression

2015-08-20 Thread Joonsoo Kim 
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 noctx API and would restore the performance as is.

Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
---
 drivers/block/zram/Kconfig | 13 +--
 drivers/block/zram/Makefile|  4 +-
 drivers/block/zram/zcomp.c | 84 +-
 drivers/block/zram/zcomp.h | 35 +-
 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  | 26 -
 9 files changed, 71 insertions(+), 219 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..36ec96f 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, ...).
@@ -14,13 +13,3 @@ config ZRAM
  disks and maybe many more.
 
  See zram.txt for more information.
-
-config ZRAM_LZ4_COMPRESS
-   bool Enable LZ4 algorithm support
-   depends on ZRAM
-   select LZ4_COMPRESS
-   select LZ4_DECOMPRESS
-   default n
-   help
- This option enables LZ4 compression algorithm support. Compression
- algorithm can be changed using `comp_algorithm' device attribute.
\ No newline at end of file
diff --git a/drivers/block/zram/Makefile b/drivers/block/zram/Makefile
index be0763f..9e2b79e 100644
--- a/drivers/block/zram/Makefile
+++ b/drivers/block/zram/Makefile
@@ -1,5 +1,3 @@
-zram-y :=  zcomp_lzo.o zcomp.o zram_drv.o
-
-zram-$(CONFIG_ZRAM_LZ4_COMPRESS) += zcomp_lz4.o
+zram-y :=  zcomp.o zram_drv.o
 
 obj-$(CONFIG_ZRAM) +=  zram.o
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index 2ad504b..d2734f2 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -13,12 +13,9 @@
 #include linux/slab.h
 #include linux/wait.h
 #include linux/sched.h
+#include linux/crypto.h
 
 #include zcomp.h
-#include zcomp_lzo.h
-#ifdef CONFIG_ZRAM_LZ4_COMPRESS
-#include zcomp_lz4.h
-#endif
 
 /*
  * single zcomp_strm backend
@@ -43,36 +40,34 @@ struct zcomp_strm_multi {
wait_queue_head_t strm_wait;
 };
 
-static struct zcomp_backend *backends[] = {
-   zcomp_lzo,
-#ifdef CONFIG_ZRAM_LZ4_COMPRESS
-   zcomp_lz4,
+static const char * const backends[] = {
+   lzo,
+#ifdef CONFIG_CRYPTO_LZ4
+   lz4,
+#endif
+#ifdef CONFIG_CRYPTO_LZ4HC
+   lz4hc,
+#endif
+#ifdef CONFIG_CRYPTO_DEFLATE
+   deflate,
+#endif
+#ifdef CONFIG_CRYPTO_842
+   842,
 #endif
NULL
 };
 
-static struct zcomp_backend *find_backend(const char *compress)
-{
-   int i = 0;
-   while (backends[i]) {
-   if

[PATCH v2 6/8] zram: change zcomp_compress interface

2015-08-20 Thread Joonsoo Kim 
zram regards zstrm's buffer as compression destination buffer, but,
it is not intuitive and there is no document about it. Providing
destination buffer to zcomp_compress() directly seems more intuitive
interface to me so this patch changes zcomp_compress interface.

Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
---
 drivers/block/zram/zcomp.c| 5 ++---
 drivers/block/zram/zcomp.h| 2 +-
 drivers/block/zram/zram_drv.c | 2 +-
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index 965d1af..2ad504b 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -307,10 +307,9 @@ void zcomp_strm_release(struct zcomp *comp, struct 
zcomp_strm *zstrm)
 }
 
 int zcomp_compress(struct zcomp *comp, struct zcomp_strm *zstrm,
-   const unsigned char *src, size_t *dst_len)
+   const unsigned char *src, unsigned char *dst, size_t *dst_len)
 {
-   return comp-backend-compress(src, zstrm-buffer, dst_len,
-   zstrm-private);
+   return comp-backend-compress(src, dst, dst_len, zstrm-private);
 }
 
 int zcomp_decompress(struct zcomp *comp, const unsigned char *src,
diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
index 46e2b9f..b2388e0 100644
--- a/drivers/block/zram/zcomp.h
+++ b/drivers/block/zram/zcomp.h
@@ -60,7 +60,7 @@ struct zcomp_strm *zcomp_strm_find(struct zcomp *comp);
 void zcomp_strm_release(struct zcomp *comp, struct zcomp_strm *zstrm);
 
 int zcomp_compress(struct zcomp *comp, struct zcomp_strm *zstrm,
-   const unsigned char *src, size_t *dst_len);
+   const unsigned char *src, unsigned char *dst, size_t *dst_len);
 
 int zcomp_decompress(struct zcomp *comp, const unsigned char *src,
size_t src_len, unsigned char *dst);
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index b088ca9..4801e4d 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -701,7 +701,7 @@ static int zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index,
goto out;
}
 
-   ret = zcomp_compress(zram-comp, zstrm, uncmem, clen);
+   ret = zcomp_compress(zram-comp, zstrm, uncmem, zstrm-buffer, clen);
if (!is_partial_io(bvec)) {
kunmap_atomic(user_mem);
user_mem = NULL;
-- 
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

[PATCH v2 2/8] crypto/lzo: support decompress_noctx

2015-08-20 Thread Joonsoo Kim 
lzo's decompression doesn't requires any scratch buffer so
it doesn't need tfm context. Hence, it can support
crypto compression noctx API and this patch implements it.

Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
---
 crypto/lzo.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/crypto/lzo.c b/crypto/lzo.c
index 9ca516b..f1844dd 100644
--- a/crypto/lzo.c
+++ b/crypto/lzo.c
@@ -80,6 +80,22 @@ static int lzo_decompress(struct crypto_tfm *tfm, const u8 
*src,
 
 }
 
+static int lzo_decompress_noctx(const u8 *src, unsigned int slen,
+   u8 *dst, unsigned int *dlen)
+{
+   int err;
+   size_t tmp_len = *dlen; /* size_t(ulong) - uint on 64 bit */
+
+   err = lzo1x_decompress_safe(src, slen, dst, tmp_len);
+
+   if (err != LZO_E_OK)
+   return -EINVAL;
+
+   *dlen = tmp_len;
+   return 0;
+
+}
+
 static struct crypto_alg alg = {
.cra_name   = lzo,
.cra_flags  = CRYPTO_ALG_TYPE_COMPRESS,
@@ -91,7 +107,7 @@ static struct crypto_alg alg = {
.coa_compress   = lzo_compress,
.coa_decompress = lzo_decompress,
.coa_compress_noctx = NULL,
-   .coa_decompress_noctx   = NULL } }
+   .coa_decompress_noctx   = lzo_decompress_noctx } }
 };
 
 static int __init lzo_mod_init(void)
-- 
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

[PATCH v2 5/8] crypto/842: support decompress_noctx

2015-08-20 Thread Joonsoo Kim 
842's decompression doesn't requires any scratch buffer so
it doesn't need tfm context. Hence, it can support
crypto compression noctx API and this patch implements it.

Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
---
 crypto/842.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/crypto/842.c b/crypto/842.c
index b6503ea..9acb595 100644
--- a/crypto/842.c
+++ b/crypto/842.c
@@ -52,6 +52,12 @@ static int crypto842_decompress(struct crypto_tfm *tfm,
return sw842_decompress(src, slen, dst, dlen);
 }
 
+static int crypto842_decompress_noctx(const u8 *src, unsigned int slen,
+ u8 *dst, unsigned int *dlen)
+{
+   return sw842_decompress(src, slen, dst, dlen);
+}
+
 static struct crypto_alg alg = {
.cra_name   = 842,
.cra_driver_name= 842-generic,
@@ -63,7 +69,7 @@ static struct crypto_alg alg = {
.coa_compress   = crypto842_compress,
.coa_decompress = crypto842_decompress,
.coa_compress_noctx = NULL,
-   .coa_decompress_noctx   = NULL } }
+   .coa_decompress_noctx   = crypto842_decompress_noctx } }
 };
 
 static int __init crypto842_mod_init(void)
-- 
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

[PATCH v2 3/8] crypyo/lz4: support decompress_noctx

2015-08-20 Thread Joonsoo Kim 
lz4's decompression doesn't requires any scratch buffer so
it doesn't need tfm context. Hence, it can support
crypto compression noctx API and this patch implements it.

Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
---
 crypto/lz4.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/crypto/lz4.c b/crypto/lz4.c
index 1848435..aa23da3 100644
--- a/crypto/lz4.c
+++ b/crypto/lz4.c
@@ -76,6 +76,21 @@ static int lz4_decompress_crypto(struct crypto_tfm *tfm, 
const u8 *src,
return err;
 }
 
+static int lz4_decompress_noctx(const u8 *src, unsigned int slen,
+   u8 *dst, unsigned int *dlen)
+{
+   int err;
+   size_t tmp_len = *dlen;
+   size_t __slen = slen;
+
+   err = lz4_decompress_unknownoutputsize(src, __slen, dst, tmp_len);
+   if (err  0)
+   return -EINVAL;
+
+   *dlen = tmp_len;
+   return err;
+}
+
 static struct crypto_alg alg_lz4 = {
.cra_name   = lz4,
.cra_flags  = CRYPTO_ALG_TYPE_COMPRESS,
@@ -88,7 +103,7 @@ static struct crypto_alg alg_lz4 = {
.coa_compress   = lz4_compress_crypto,
.coa_decompress = lz4_decompress_crypto,
.coa_compress_noctx = NULL,
-   .coa_decompress_noctx   = NULL } }
+   .coa_decompress_noctx   = lz4_decompress_noctx } }
 };
 
 static int __init lz4_mod_init(void)
-- 
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

[PATCH v2 4/8] crypto/lz4hc: support decompress_noctx

2015-08-20 Thread Joonsoo Kim 
lz4hc's decompression doesn't requires any scratch buffer so
it doesn't need tfm context. Hence, it can support
crypto compression noctx API and this patch implements it.

Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
---
 crypto/lz4hc.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/crypto/lz4hc.c b/crypto/lz4hc.c
index bcf0baa..a529620 100644
--- a/crypto/lz4hc.c
+++ b/crypto/lz4hc.c
@@ -76,6 +76,21 @@ static int lz4hc_decompress_crypto(struct crypto_tfm *tfm, 
const u8 *src,
return err;
 }
 
+static int lz4hc_decompress_noctx(const u8 *src, unsigned int slen,
+ u8 *dst, unsigned int *dlen)
+{
+   int err;
+   size_t tmp_len = *dlen;
+   size_t __slen = slen;
+
+   err = lz4_decompress_unknownoutputsize(src, __slen, dst, tmp_len);
+   if (err  0)
+   return -EINVAL;
+
+   *dlen = tmp_len;
+   return err;
+}
+
 static struct crypto_alg alg_lz4hc = {
.cra_name   = lz4hc,
.cra_flags  = CRYPTO_ALG_TYPE_COMPRESS,
@@ -88,7 +103,7 @@ static struct crypto_alg alg_lz4hc = {
.coa_compress   = lz4hc_compress_crypto,
.coa_decompress = lz4hc_decompress_crypto,
.coa_compress_noctx = NULL,
-   .coa_decompress_noctx   = NULL } }
+   .coa_decompress_noctx   = lz4hc_decompress_noctx } }
 };
 
 static int __init lz4hc_mod_init(void)
-- 
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 v1 1/4] dmaengine: Add support for new feature CRC32C

2015-08-20 Thread Vinod Koul 
On Thu, Aug 20, 2015 at 11:59:07AM +0530, Rameshwar Sahu wrote:
 Hi Vinod,
 
 On Thu, Aug 20, 2015 at 10:56 AM, Vinod Koul vinod.k...@intel.com wrote:
  On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote:
  This patch adds support for new feature CRC32C calculation in
  dmaengine framework.
 
  Looks okay can you please update Documentation also
 
 Thanks, I will update Documentation.

Also add a wrapper for new API

-- 
~Vinod

--
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 0/2] crypto: skcipher - Introduce new skcipher interface

2015-08-20 Thread Herbert Xu 
Hi:

These two patches introduce a new skcipher interface that aims
to replace the existing blkcipher and ablkcipher interfaces.  A
bit of history, the blkcipher interface was originally split from
the cipher interface in order to differentiate the underly block
cipher algorithm from the modes such as ECB/CBC.  Later ablkcipher
was added in order to support hardware devices.

Unlike the shash/ahash split, both blkcipher and ablkcipher operate
on SG lists.  Therefore there is really no need to maintain them
as separate interfaces.

The new skcipher interface is essentially identical to ablkcipher
but without the implicit IV generators that have been rendered
obsolete by the new AEAD interface.

The next step in the process is to convert existing users over
to skcipher.

Cheers,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v2 1/8] crypto: support (de)compression API that doesn't require tfm object

2015-08-20 Thread Herbert Xu 
On Thu, Aug 20, 2015 at 04:52:17PM +0900, Joonsoo Kim wrote:
 
 Hmm... I guess there is no problem. crypto_alg object fetched by
 crypto_get_comp() introduced in this patch could be hardware device
 algorithm which is same one that we can eventually fetch from tfm object.
 So, this approach would correctly track the crypto_alg regardless
 it is a hardware one or not. If there is some dependency between
 algorithm and tfm, it can't support _noctx API. Am I missing
 something?

Your approach limits what hardware devices we can support in
future.  It is fairly common for hardware drivers to only allocate
resources when a tfm is created.  With your tfmless interface,
the driver would have to unconditionally allocate resources.

It is essentially a global tfm without the tfm.

 Yes, I thought this way before, but, current way is much simpler so
 I try it first. If it is not acceptable, I will implement this
 approach.

Please go with a global tfm.

Thanks,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: hash - Add AHASH_REQUEST_ON_STACK

2015-08-20 Thread Herbert Xu 
This patch adds the helper AHASH_REQUEST_ON_STACK for those users
of ahash that are synchronous only.

Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---

 include/crypto/hash.h |5 +
 1 file changed, 5 insertions(+)

diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index 57c8a6e..8e920b4 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -63,6 +63,11 @@ struct ahash_request {
void *__ctx[] CRYPTO_MINALIGN_ATTR;
 };
 
+#define AHASH_REQUEST_ON_STACK(name, ahash) \
+   char __##name##_desc[sizeof(struct ahash_request) + \
+   crypto_ahash_reqsize(ahash)] CRYPTO_MINALIGN_ATTR; \
+   struct ahash_request *name = (void *)__##name##_desc
+
 /**
  * struct ahash_alg - asynchronous message digest definition
  * @init: Initialize the transformation context. Intended only to initialize 
the
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: un4i-ss-cipher.c warning

2015-08-20 Thread Maxime Ripard 
On Thu, Aug 20, 2015 at 01:29:03PM +0800, Herbert Xu wrote:
 On Wed, Aug 19, 2015 at 04:35:36PM +0200, Michal Suchanek wrote:
  Hello,
  
  when building a kernel with sunxi crypto driver as merged into the
  sinxi-wip branch I get a compiler warning.
  
  I am not sure this is the latest version of the driver. It does not
  seem to be in mainline yet.
 
 The warning appears to be spurious as the code always ends up
 initialising todo before using it.

Not in the dev_dbg call line 258. If ileft was negative or null, todo
isn't assigned to anything.

I'm not sure whether initializing todo to 0 is the right thing to do
though. Corentin?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH v1 2/4] dmaengine: xgene-dma: Add support for CRC32C calculation via DMA engine

2015-08-20 Thread Vinod Koul 
On Thu, Aug 20, 2015 at 12:23:50PM +0530, Rameshwar Sahu wrote:
 Hi Vinod,
 
 On Thu, Aug 20, 2015 at 11:10 AM, Vinod Koul vinod.k...@intel.com wrote:
  On Thu, Jul 30, 2015 at 05:41:06PM +0530, Rameshwar Prasad Sahu wrote:
  + /* Invalidate unused source address field */
  + for (; i  4; i++)
  + xgene_dma_invalidate_buffer(xgene_dma_lookup_ext8(desc2, i));
  +
  + /* Check whether requested buffer processed */
  + if (nbytes) {
  + chan_err(chan, Src count crossed maximum limit\n);
  + return -EINVAL;
  no cleanup ?
 Here not required, cleanup I am doing in parent function from where
 this function is getting called in case of failure.
 
  +struct dma_async_tx_descriptor *xgene_dma_prep_flyby(
  + struct xgene_dma_chan *chan, struct scatterlist *src_sg,
  + size_t len, u32 seed, u8 *result, unsigned long flags, u8 opcode)
  please fix style here
 
 Could you explain me What kind of coding style you would like here ??

See CodingStyle Chapter 2

-- 
~Vinod

--
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 v1 1/4] dmaengine: Add support for new feature CRC32C

2015-08-20 Thread Rameshwar Sahu 
On Thu, Aug 20, 2015 at 12:38 PM, Vinod Koul vinod.k...@intel.com wrote:
 On Thu, Aug 20, 2015 at 11:59:07AM +0530, Rameshwar Sahu wrote:
 Hi Vinod,

 On Thu, Aug 20, 2015 at 10:56 AM, Vinod Koul vinod.k...@intel.com wrote:
  On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote:
  This patch adds support for new feature CRC32C calculation in
  dmaengine framework.
 
  Looks okay can you please update Documentation also

 Thanks, I will update Documentation.

 Also add a wrapper for new API
Okay

 --
 ~Vinod

--
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 v2 1/8] crypto: support (de)compression API that doesn't require tfm object

2015-08-20 Thread Herbert Xu 
On Thu, Aug 20, 2015 at 03:34:57PM +0900, Joonsoo Kim wrote:
 Until now, tfm object embeds (de)compression context in it and
 (de)compression in crypto API requires tfm object to use
 this context. But, there are some algorithms that doesn't need
 such context to operate. Therefore, this patch introduce new crypto
 compression API that call (de)compression function via crypto_alg,
 instead of tfm object. crypto_alg is required to get appropriate
 (de)compression function pointer. This can reduce overhead of
 maintaining multiple tfm if (de)compression doesn't require
 any context to operate.
 
 Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com

This isn't going to fly I'm afraid.  The main purpose of a tfm
is not to allocate memory but to track the crypto_alg object
which could be a hardware device.

So you're not going to get away with not allocating it.

What you can do for these contextless algorithms (and by definition
every compression algorithm is conxteless) is to allocate a system-
wide tfm that is used by everybody, or at least by every one within
your subsystem.

Cheers,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v2 1/8] crypto: support (de)compression API that doesn't require tfm object

2015-08-20 Thread Joonsoo Kim 
On Thu, Aug 20, 2015 at 03:50:35PM +0800, Herbert Xu wrote:
 On Thu, Aug 20, 2015 at 04:52:17PM +0900, Joonsoo Kim wrote:
  
  Hmm... I guess there is no problem. crypto_alg object fetched by
  crypto_get_comp() introduced in this patch could be hardware device
  algorithm which is same one that we can eventually fetch from tfm object.
  So, this approach would correctly track the crypto_alg regardless
  it is a hardware one or not. If there is some dependency between
  algorithm and tfm, it can't support _noctx API. Am I missing
  something?
 
 Your approach limits what hardware devices we can support in
 future.  It is fairly common for hardware drivers to only allocate
 resources when a tfm is created.  With your tfmless interface,
 the driver would have to unconditionally allocate resources.

Ah...Okay. thanks for clarifying.

 
 It is essentially a global tfm without the tfm.
 
  Yes, I thought this way before, but, current way is much simpler so
  I try it first. If it is not acceptable, I will implement this
  approach.
 
 Please go with a global tfm.

Okay. Will do that in next spin.

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: un4i-ss-cipher.c warning

2015-08-20 Thread Herbert Xu 
On Thu, Aug 20, 2015 at 08:39:00AM +0200, Maxime Ripard wrote:

 Not in the dev_dbg call line 258. If ileft was negative or null, todo
 isn't assigned to anything.

If ileft starts out being = 0, then oleft == ileft will also be
= 0, in which case the loop never executes.

Cheers,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: Recent AEAD change: testmgr.c change needed?

2015-08-20 Thread Herbert Xu 
On Wed, Aug 19, 2015 at 08:45:50PM +0800, Herbert Xu wrote:

  [11154.278466] alg: No test for ccm_base(ctr(aes-asm),aes-asm) 
  (ccm_base(ctr(aes-asm),aes-asm))
  [11174.819535] alg: No test for gcm(aes-asm) (gcm_base(ctr(aes-asm),ghash-
  clmulni))
  [11174.819610] alg: No test for rfc4106(gcm(aes-asm)) 
  (rfc4106(gcm_base(ctr(aes-asm),ghash-clmulni)))
 
 Ditto.  gcm should also canonicalise aes-asm in its cra_name.

I had a look and it seems that we need to fix ctr first to get
the canonicalised name.  So I'll revisit this after completing
the skcipher work.

Cheers,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v1 1/4] dmaengine: Add support for new feature CRC32C

2015-08-20 Thread Rameshwar Sahu 
Hi Vinod,

On Thu, Aug 20, 2015 at 10:56 AM, Vinod Koul vinod.k...@intel.com wrote:
 On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote:
 This patch adds support for new feature CRC32C calculation in
 dmaengine framework.

 Looks okay can you please update Documentation also

Thanks, I will update Documentation.

 --
 ~Vinod

--
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 v2 0/8] zram: introduce crypto compress noctx API and use it on zram

2015-08-20 Thread Joonsoo Kim 
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.

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
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

Read10411701.88 6426911.62  9423894.38 
Re-read 10017386.62 6428218.88  1163.50 

Thanks.

Joonsoo Kim (8):
  crypto: support (de)compression API that doesn't require tfm object
  crypto/lzo: support decompress_noctx
  crypyo/lz4: support decompress_noctx
  crypto/lz4hc: support decompress_noctx
  crypto/842: support decompress_noctx
  zram: change zcomp_compress interface
  zram: use crypto API for compression
  zram: use decompress_noctx

 crypto/842.c   |  10 +++-
 crypto/compress.c  |  20 
 crypto/crypto_null.c   |   4 +-
 crypto/deflate.c   |   4 +-
 crypto/lz4.c   |  19 ++-
 crypto/lz4hc.c |  19 ++-
 crypto/lzo.c   |  20 +++-
 drivers/block/zram/Kconfig |  13 +
 drivers/block/zram/Makefile|   4 +-
 drivers/block/zram/zcomp.c | 113 +
 drivers/block/zram/zcomp.h |  44 +++-
 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  |  29 +++
 include/linux/crypto.h |  31 +++
 17 files changed, 229 insertions(+), 229 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

[PATCH v2 1/8] crypto: support (de)compression API that doesn't require tfm object

2015-08-20 Thread Joonsoo Kim 
Until now, tfm object embeds (de)compression context in it and
(de)compression in crypto API requires tfm object to use
this context. But, there are some algorithms that doesn't need
such context to operate. Therefore, this patch introduce new crypto
compression API that call (de)compression function via crypto_alg,
instead of tfm object. crypto_alg is required to get appropriate
(de)compression function pointer. This can reduce overhead of
maintaining multiple tfm if (de)compression doesn't require
any context to operate.

Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
---
 crypto/842.c   |  4 +++-
 crypto/compress.c  | 20 
 crypto/crypto_null.c   |  4 +++-
 crypto/deflate.c   |  4 +++-
 crypto/lz4.c   |  4 +++-
 crypto/lz4hc.c |  4 +++-
 crypto/lzo.c   |  4 +++-
 include/linux/crypto.h | 31 +++
 8 files changed, 69 insertions(+), 6 deletions(-)

diff --git a/crypto/842.c b/crypto/842.c
index 98e387e..b6503ea 100644
--- a/crypto/842.c
+++ b/crypto/842.c
@@ -61,7 +61,9 @@ 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_compress_noctx = NULL,
+   .coa_decompress_noctx   = NULL } }
 };
 
 static int __init crypto842_mod_init(void)
diff --git a/crypto/compress.c b/crypto/compress.c
index c33f076..f27eee0 100644
--- a/crypto/compress.c
+++ b/crypto/compress.c
@@ -33,6 +33,26 @@ static int crypto_decompress(struct crypto_tfm *tfm,
   dlen);
 }
 
+struct crypto_alg *crypto_get_comp(const char *alg_name, u32 type, u32 mask)
+{
+   struct crypto_alg *alg;
+
+   type = ~CRYPTO_ALG_TYPE_MASK;
+   type |= CRYPTO_ALG_TYPE_COMPRESS;
+   mask |= CRYPTO_ALG_TYPE_MASK;
+
+   alg = crypto_alg_mod_lookup(alg_name, type, mask);
+   if (!IS_ERR(alg))
+   return alg;
+
+   return NULL;
+}
+
+void crypto_put_comp(struct crypto_alg *alg)
+{
+   crypto_mod_put(alg);
+}
+
 int crypto_init_compress_ops(struct crypto_tfm *tfm)
 {
struct compress_tfm *ops = tfm-crt_compress;
diff --git a/crypto/crypto_null.c b/crypto/crypto_null.c
index 941c9a4..e397d1c 100644
--- a/crypto/crypto_null.c
+++ b/crypto/crypto_null.c
@@ -146,7 +146,9 @@ static struct crypto_alg null_algs[3] = { {
.cra_module =   THIS_MODULE,
.cra_u  =   { .compress = {
.coa_compress   =   null_compress,
-   .coa_decompress =   null_compress } }
+   .coa_decompress =   null_compress,
+   .coa_compress_noctx =   NULL,
+   .coa_decompress_noctx   =   NULL } }
 } };
 
 MODULE_ALIAS_CRYPTO(compress_null);
diff --git a/crypto/deflate.c b/crypto/deflate.c
index 95d8d37..dee4daf 100644
--- a/crypto/deflate.c
+++ b/crypto/deflate.c
@@ -203,7 +203,9 @@ static struct crypto_alg alg = {
.cra_exit   = deflate_exit,
.cra_u  = { .compress = {
.coa_compress   = deflate_compress,
-   .coa_decompress = deflate_decompress } }
+   .coa_decompress = deflate_decompress,
+   .coa_compress_noctx = NULL,
+   .coa_decompress_noctx   = NULL } }
 };
 
 static int __init deflate_mod_init(void)
diff --git a/crypto/lz4.c b/crypto/lz4.c
index aefbcea..1848435 100644
--- a/crypto/lz4.c
+++ b/crypto/lz4.c
@@ -86,7 +86,9 @@ static struct crypto_alg alg_lz4 = {
.cra_exit   = lz4_exit,
.cra_u  = { .compress = {
.coa_compress   = lz4_compress_crypto,
-   .coa_decompress = lz4_decompress_crypto } }
+   .coa_decompress = lz4_decompress_crypto,
+   .coa_compress_noctx = NULL,
+   .coa_decompress_noctx   = NULL } }
 };
 
 static int __init lz4_mod_init(void)
diff --git a/crypto/lz4hc.c b/crypto/lz4hc.c
index a1d3b5b..bcf0baa 100644
--- a/crypto/lz4hc.c
+++ b/crypto/lz4hc.c
@@ -86,7 +86,9 @@ static struct crypto_alg alg_lz4hc = {
.cra_exit   = lz4hc_exit,
.cra_u  = { .compress = {
.coa_compress   = lz4hc_compress_crypto,
-   .coa_decompress = lz4hc_decompress_crypto } }
+   .coa_decompress = lz4hc_decompress_crypto,
+   .coa_compress_noctx = NULL,
+   .coa_decompress_noctx   = NULL } }
 };
 
 static int __init lz4hc_mod_init(void)
diff --git a/crypto/lzo.c b/crypto/lzo.c
index 4b3e925..9ca516b 100644
--- a/crypto/lzo.c
+++ b/crypto/lzo.c
@@ -89,7 +89,9 @@ static struct crypto_alg alg = {
.cra_exit   = lzo_exit,
.cra_u  = { .compress = {
.coa_compress   = lzo_compress,
-

Re: [PATCH v1 3/4] Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver

2015-08-20 Thread Rameshwar Sahu 
Hi Vinod,

On Thu, Aug 20, 2015 at 11:18 AM, Vinod Koul vinod.k...@intel.com wrote:
 On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
 + nents = sg_nents(req-src);
 + sg_count = dma_map_sg(dev, req-src, nents, DMA_TO_DEVICE);
 + if (!sg_count) {
 + dev_err(dev, Failed to map src sg);
 + return -ENOMEM;
 mapping error shouldn't be no mem error
Okay, I guess then -EIO will be fine here??

 + }
 +
 + if (sg_count  XGENE_DMA_MAX_FLYBY_SRC_CNT) {
 + dev_err(dev, Unsupported src sg len\n);
 would be worth printing length
Okay,

 + goto err;
 + }
 +
 + flags = DMA_CTRL_ACK;
 why ACK?
My understanding about DMA_CTRL_ACK is dma engine driver can
re-use/free this descriptor once operation completed in cleanup path.
Am I correct ??
But yes, I need to look on this because recently you have added one
more descriptor flag.


 +
 + tx = dchan-device-device_prep_dma_crc32c(dchan, req-src,
 +req-nbytes,
 +reqctx-seed,
 +req-result,
 +flags);
 We should add helper for this
Okay

 --
 ~Vinod

--
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 2/2] crypto: testmgr - Use new skcipher interface

2015-08-20 Thread Herbert Xu 
This patch replaces uses of blkcipher and ablkcipher with the
new skcipher interface.

Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---

 crypto/testmgr.c |   61 ---
 1 file changed, 32 insertions(+), 29 deletions(-)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index d0a42bd..e6ed04b 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -22,6 +22,7 @@
 
 #include crypto/aead.h
 #include crypto/hash.h
+#include crypto/skcipher.h
 #include linux/err.h
 #include linux/fips.h
 #include linux/module.h
@@ -921,15 +922,15 @@ out_nobuf:
return ret;
 }
 
-static int __test_skcipher(struct crypto_ablkcipher *tfm, int enc,
+static int __test_skcipher(struct crypto_skcipher *tfm, int enc,
   struct cipher_testvec *template, unsigned int tcount,
   const bool diff_dst, const int align_offset)
 {
const char *algo =
-   crypto_tfm_alg_driver_name(crypto_ablkcipher_tfm(tfm));
+   crypto_tfm_alg_driver_name(crypto_skcipher_tfm(tfm));
unsigned int i, j, k, n, temp;
char *q;
-   struct ablkcipher_request *req;
+   struct skcipher_request *req;
struct scatterlist sg[8];
struct scatterlist sgout[8];
const char *e, *d;
@@ -958,15 +959,15 @@ static int __test_skcipher(struct crypto_ablkcipher *tfm, 
int enc,
 
init_completion(result.completion);
 
-   req = ablkcipher_request_alloc(tfm, GFP_KERNEL);
+   req = skcipher_request_alloc(tfm, GFP_KERNEL);
if (!req) {
pr_err(alg: skcipher%s: Failed to allocate request for %s\n,
   d, algo);
goto out;
}
 
-   ablkcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
-   tcrypt_complete, result);
+   skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
+ tcrypt_complete, result);
 
j = 0;
for (i = 0; i  tcount; i++) {
@@ -987,15 +988,16 @@ static int __test_skcipher(struct crypto_ablkcipher *tfm, 
int enc,
data += align_offset;
memcpy(data, template[i].input, template[i].ilen);
 
-   crypto_ablkcipher_clear_flags(tfm, ~0);
+   crypto_skcipher_clear_flags(tfm, ~0);
if (template[i].wk)
-   crypto_ablkcipher_set_flags(tfm, 
CRYPTO_TFM_REQ_WEAK_KEY);
+   crypto_skcipher_set_flags(tfm,
+ CRYPTO_TFM_REQ_WEAK_KEY);
 
-   ret = crypto_ablkcipher_setkey(tfm, template[i].key,
-  template[i].klen);
+   ret = crypto_skcipher_setkey(tfm, template[i].key,
+template[i].klen);
if (!ret == template[i].fail) {
pr_err(alg: skcipher%s: setkey failed on test %d for 
%s: flags=%x\n,
-  d, j, algo, crypto_ablkcipher_get_flags(tfm));
+  d, j, algo, crypto_skcipher_get_flags(tfm));
goto out;
} else if (ret)
continue;
@@ -1007,10 +1009,10 @@ static int __test_skcipher(struct crypto_ablkcipher 
*tfm, int enc,
sg_init_one(sgout[0], data, template[i].ilen);
}
 
-   ablkcipher_request_set_crypt(req, sg, (diff_dst) ? sgout : sg,
-template[i].ilen, iv);
-   ret = enc ? crypto_ablkcipher_encrypt(req) :
-   crypto_ablkcipher_decrypt(req);
+   skcipher_request_set_crypt(req, sg, (diff_dst) ? sgout : sg,
+  template[i].ilen, iv);
+   ret = enc ? crypto_skcipher_encrypt(req) :
+   crypto_skcipher_decrypt(req);
 
switch (ret) {
case 0:
@@ -1054,15 +1056,16 @@ static int __test_skcipher(struct crypto_ablkcipher 
*tfm, int enc,
memset(iv, 0, MAX_IVLEN);
 
j++;
-   crypto_ablkcipher_clear_flags(tfm, ~0);
+   crypto_skcipher_clear_flags(tfm, ~0);
if (template[i].wk)
-   crypto_ablkcipher_set_flags(tfm, 
CRYPTO_TFM_REQ_WEAK_KEY);
+   crypto_skcipher_set_flags(tfm,
+ CRYPTO_TFM_REQ_WEAK_KEY);
 
-   ret = crypto_ablkcipher_setkey(tfm, template[i].key,
-  template[i].klen);
+   ret = crypto_skcipher_setkey(tfm, template[i].key,
+template[i].klen);
if (!ret == template[i].fail) {
pr_err(alg: skcipher%s: setkey failed on chunk test %d 
for %s: flags=%x\n,

[PATCH 1/2] crypto: skcipher - Add top-level skcipher interface

2015-08-20 Thread Herbert Xu 
This patch introduces the crypto skcipher interface which aims
to replace both blkcipher and ablkcipher.

It's very similar to the existing ablkcipher interface.  The
main difference is the removal of the givcrypt interface.  In
order to make the transition easier for blkcipher users, there
is a helper SKCIPHER_REQUEST_ON_STACK which can be used to place
a request on the stack for synchronous transforms.

Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---

 crypto/Makefile|1 
 crypto/skcipher.c  |  245 +++
 include/crypto/internal/skcipher.h |   15 +
 include/crypto/skcipher.h  |  391 -
 4 files changed, 651 insertions(+), 1 deletion(-)

diff --git a/crypto/Makefile b/crypto/Makefile
index f6229ae..e2c5981 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_CRYPTO_AEAD2) += aead.o
 
 crypto_blkcipher-y := ablkcipher.o
 crypto_blkcipher-y += blkcipher.o
+crypto_blkcipher-y += skcipher.o
 obj-$(CONFIG_CRYPTO_BLKCIPHER2) += crypto_blkcipher.o
 obj-$(CONFIG_CRYPTO_BLKCIPHER2) += chainiv.o
 obj-$(CONFIG_CRYPTO_BLKCIPHER2) += eseqiv.o
diff --git a/crypto/skcipher.c b/crypto/skcipher.c
new file mode 100644
index 000..dd5fc1b
--- /dev/null
+++ b/crypto/skcipher.c
@@ -0,0 +1,245 @@
+/*
+ * Symmetric key cipher operations.
+ *
+ * Generic encrypt/decrypt wrapper for ciphers, handles operations across
+ * multiple page boundaries by using temporary blocks.  In user context,
+ * the kernel is given a chance to schedule us once per page.
+ *
+ * Copyright (c) 2015 Herbert Xu herb...@gondor.apana.org.au
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+
+#include crypto/internal/skcipher.h
+#include linux/bug.h
+#include linux/module.h
+
+#include internal.h
+
+static unsigned int crypto_skcipher_extsize(struct crypto_alg *alg)
+{
+   if (alg-cra_type == crypto_blkcipher_type)
+   return sizeof(struct crypto_blkcipher *);
+
+   BUG_ON(alg-cra_type != crypto_ablkcipher_type 
+  alg-cra_type != crypto_givcipher_type);
+
+   return sizeof(struct crypto_ablkcipher *);
+}
+
+static int skcipher_setkey_blkcipher(struct crypto_skcipher *tfm,
+const u8 *key, unsigned int keylen)
+{
+   struct crypto_blkcipher **ctx = crypto_skcipher_ctx(tfm);
+   struct crypto_blkcipher *blkcipher = *ctx;
+   int err;
+
+   crypto_blkcipher_clear_flags(blkcipher, ~0);
+   crypto_blkcipher_set_flags(blkcipher, crypto_skcipher_get_flags(tfm) 
+ CRYPTO_TFM_REQ_MASK);
+   err = crypto_blkcipher_setkey(blkcipher, key, keylen);
+   crypto_skcipher_set_flags(tfm, crypto_blkcipher_get_flags(blkcipher) 
+  CRYPTO_TFM_RES_MASK);
+
+   return err;
+}
+
+static int skcipher_crypt_blkcipher(struct skcipher_request *req,
+   int (*crypt)(struct blkcipher_desc *,
+struct scatterlist *,
+struct scatterlist *,
+unsigned int))
+{
+   struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
+   struct crypto_blkcipher **ctx = crypto_skcipher_ctx(tfm);
+   struct blkcipher_desc desc = {
+   .tfm = *ctx,
+   .info = req-iv,
+   .flags = req-base.flags,
+   };
+
+
+   return crypt(desc, req-dst, req-src, req-cryptlen);
+}
+
+static int skcipher_encrypt_blkcipher(struct skcipher_request *req)
+{
+   struct crypto_skcipher *skcipher = crypto_skcipher_reqtfm(req);
+   struct crypto_tfm *tfm = crypto_skcipher_tfm(skcipher);
+   struct blkcipher_alg *alg = tfm-__crt_alg-cra_blkcipher;
+
+   return skcipher_crypt_blkcipher(req, alg-encrypt);
+}
+
+static int skcipher_decrypt_blkcipher(struct skcipher_request *req)
+{
+   struct crypto_skcipher *skcipher = crypto_skcipher_reqtfm(req);
+   struct crypto_tfm *tfm = crypto_skcipher_tfm(skcipher);
+   struct blkcipher_alg *alg = tfm-__crt_alg-cra_blkcipher;
+
+   return skcipher_crypt_blkcipher(req, alg-decrypt);
+}
+
+static void crypto_exit_skcipher_ops_blkcipher(struct crypto_tfm *tfm)
+{
+   struct crypto_blkcipher **ctx = crypto_tfm_ctx(tfm);
+
+   crypto_free_blkcipher(*ctx);
+}
+
+int crypto_init_skcipher_ops_blkcipher(struct crypto_tfm *tfm)
+{
+   struct crypto_alg *calg = tfm-__crt_alg;
+   struct crypto_skcipher *skcipher = __crypto_skcipher_cast(tfm);
+   struct crypto_blkcipher **ctx = crypto_tfm_ctx(tfm);
+   struct crypto_blkcipher *blkcipher;
+   struct crypto_tfm *btfm;
+
+   if

Re: un4i-ss-cipher.c warning

2015-08-20 Thread Corentin LABBE 

On 19/08/2015 16:35, Michal Suchanek wrote:

Hello,

when building a kernel with sunxi crypto driver as merged into the
sinxi-wip branch I get a compiler warning.

I am not sure this is the latest version of the driver. It does not
seem to be in mainline yet.

Thanks

Michal

In file included from /scratch/build/linux/include/linux/printk.h:277:0,
  from /scratch/build/linux/include/linux/kernel.h:13,
  from /scratch/build/linux/include/linux/clk.h:16,
  from
/scratch/build/linux/drivers/crypto/sunxi-ss/sun4i-ss.h:15,
  from
/scratch/build/linux/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c:17:
/scratch/build/linux/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c: In
function ‘sun4i_ss_cipher_poll’:
/scratch/build/linux/include/linux/dynamic_debug.h:86:3: warning:
‘todo’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
__dynamic_dev_dbg(descriptor, dev, fmt, \
^
/scratch/build/linux/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c:144:15:
note: ‘todo’ was declared here
   unsigned int todo;



Hello

Thanks for the report, strange that I do not have that warning.
todo is always initialized, since oleft and ileft are always  0 at start.
But setting todo to 0 is a simple fix.
The following patch will suppress the warning.

Regards

-- 8 --
From 67f2d0749041b08c4c4ad671ab710b3b83f6dfd3 Mon Sep 17 00:00:00 2001
From: LABBE Corentin clabbe.montj...@gmail.com
Date: Thu, 20 Aug 2015 12:18:46 +0200
Subject: [PATCH] crypto: sun4i-ss: suppress the todo uninitialized warning

Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com
---
 drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c 
b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
index e070c31..9299914 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
@@ -32,7 +32,7 @@ static int sun4i_ss_opti_poll(struct ablkcipher_request *areq)
int i, err = 0;
unsigned int ileft = areq-nbytes;
unsigned int oleft = areq-nbytes;
-   unsigned int todo;
+   unsigned int todo = 0;
struct sg_mapping_iter mi, mo;
unsigned int oi, oo; /* offset for in and out */

@@ -141,7 +141,7 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request 
*areq)
int i, err = 0;
unsigned int ileft = areq-nbytes;
unsigned int oleft = areq-nbytes;
-   unsigned int todo;
+   unsigned int todo = 0;
struct sg_mapping_iter mi, mo;
unsigned int oi, oo;/* offset for in and out */
char buf[4 * SS_RX_MAX];/* buffer for linearize SG src */
--
2.4.6

--
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: un4i-ss-cipher.c warning

2015-08-20 Thread Herbert Xu 
On Thu, Aug 20, 2015 at 03:56:39PM +0200, Corentin LABBE wrote:
 
 Thanks for the report, strange that I do not have that warning.
 todo is always initialized, since oleft and ileft are always  0 at start.
 But setting todo to 0 is a simple fix.
 The following patch will suppress the warning.

Nack.  Please do not fix spurious uninitialised warnings in this
way.  Not only is this pointless but if someone introduced a real
uninitialised bug later on we'd never catch it because of this.

Cheers,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v1 2/4] dmaengine: xgene-dma: Add support for CRC32C calculation via DMA engine

2015-08-20 Thread Rameshwar Sahu 
Hi Vinod,

On Thu, Aug 20, 2015 at 11:10 AM, Vinod Koul vinod.k...@intel.com wrote:
 On Thu, Jul 30, 2015 at 05:41:06PM +0530, Rameshwar Prasad Sahu wrote:
 + /* Invalidate unused source address field */
 + for (; i  4; i++)
 + xgene_dma_invalidate_buffer(xgene_dma_lookup_ext8(desc2, i));
 +
 + /* Check whether requested buffer processed */
 + if (nbytes) {
 + chan_err(chan, Src count crossed maximum limit\n);
 + return -EINVAL;
 no cleanup ?
Here not required, cleanup I am doing in parent function from where
this function is getting called in case of failure.

 +struct dma_async_tx_descriptor *xgene_dma_prep_flyby(
 + struct xgene_dma_chan *chan, struct scatterlist *src_sg,
 + size_t len, u32 seed, u8 *result, unsigned long flags, u8 opcode)
 please fix style here

Could you explain me What kind of coding style you would like here ??

 +struct dma_async_tx_descriptor *xgene_dma_prep_crc32c(
 + struct dma_chan *dchan, struct scatterlist *src_sg,
 + size_t len, u32 seed, u8 *result, unsigned long flags)
 here too

 @@ -1309,8 +1512,13 @@ static void xgene_dma_setup_ring(struct 
 xgene_dma_ring *ring)
 ring-pdma-csr_ring + XGENE_DMA_RING_ID);

   /* Set DMA ring buffer */
 - iowrite32(XGENE_DMA_RING_ID_BUF_SETUP(ring-num),
 -   ring-pdma-csr_ring + XGENE_DMA_RING_ID_BUF);
 + ring_id_buf = XGENE_DMA_RING_ID_BUF_SETUP(ring-num);
 +
 + if (ring-is_bufpool)
 + ring_id_buf |= XGENE_DMA_RING_IS_BUFPOOL;
 +
 + iowrite32(ring_id_buf, ring-pdma-csr_ring +
 +   XGENE_DMA_RING_ID_BUF);
 pls fix style here
I didn't see any alignment issue here, just follow checkpatch that
argument should start just after function( in next line also.

 --
 ~Vinod
--
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 v2 1/8] crypto: support (de)compression API that doesn't require tfm object

2015-08-20 Thread Joonsoo Kim 
On Thu, Aug 20, 2015 at 02:47:28PM +0800, Herbert Xu wrote:
 On Thu, Aug 20, 2015 at 03:34:57PM +0900, Joonsoo Kim wrote:
  Until now, tfm object embeds (de)compression context in it and
  (de)compression in crypto API requires tfm object to use
  this context. But, there are some algorithms that doesn't need
  such context to operate. Therefore, this patch introduce new crypto
  compression API that call (de)compression function via crypto_alg,
  instead of tfm object. crypto_alg is required to get appropriate
  (de)compression function pointer. This can reduce overhead of
  maintaining multiple tfm if (de)compression doesn't require
  any context to operate.
  
  Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
 
 This isn't going to fly I'm afraid.  The main purpose of a tfm
 is not to allocate memory but to track the crypto_alg object
 which could be a hardware device.
 
 So you're not going to get away with not allocating it.

Hmm... I guess there is no problem. crypto_alg object fetched by
crypto_get_comp() introduced in this patch could be hardware device
algorithm which is same one that we can eventually fetch from tfm object.
So, this approach would correctly track the crypto_alg regardless
it is a hardware one or not. If there is some dependency between
algorithm and tfm, it can't support _noctx API. Am I missing
something?

 
 What you can do for these contextless algorithms (and by definition
 every compression algorithm is conxteless) is to allocate a system-
 wide tfm that is used by everybody, or at least by every one within
 your subsystem.

Yes, I thought this way before, but, current way is much simpler so
I try it first. If it is not acceptable, I will implement this
approach.

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