Re: [PATCH] hw_random: core: Remove unnecessary new line in MODULE_PARM_DESC

2017-10-30 Thread Herbert Xu 
On Thu, Oct 26, 2017 at 10:00:29PM +0530, PrasannaKumar Muralidharan wrote:
> While using MODULE_PARM_DESC there is a new line which is not required.
> Remove it.
> 
> Signed-off-by: PrasannaKumar Muralidharan 

Please stop sending pointless patches like this.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] hw_random: Include device.h instead of declaring struct device

2017-10-30 Thread Herbert Xu 
On Thu, Oct 26, 2017 at 07:12:08PM +0530, PrasannaKumar Muralidharan wrote:
> Include linux/device.h instead of declaring struct device.
> 
> Signed-off-by: PrasannaKumar Muralidharan 

Nack.  We should not include a header file when a simple forward
declaration is enough.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Crypto Fixes for 4.14

2017-10-30 Thread Herbert Xu 
Hi Linus: 

This push fixes an objtool regression.


Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus


Jason A. Donenfeld (1):
  crypto: x86/chacha20 - satisfy stack validation 2.0

 arch/x86/crypto/chacha20-avx2-x86_64.S  |4 ++--
 arch/x86/crypto/chacha20-ssse3-x86_64.S |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH] staging: ccree: fix 64 bit scatter/gather DMA ops

2017-10-30 Thread Gilad Ben-Yossef 
Fix a wrong offset used in splitting a 64 DMA address to MSB/LSB
parts needed for scatter/gather HW descriptors causing operations
relying on them to fail on 64 bit platforms.

Fixes: c6f7f2f4591f ("staging: ccree: refactor LLI access macros")
Reported-by: Stuart Yoder 
Signed-off-by: Gilad Ben-Yossef 
Cc: sta...@vger.kernel.org
---
 drivers/staging/ccree/cc_lli_defs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ccree/cc_lli_defs.h 
b/drivers/staging/ccree/cc_lli_defs.h
index 851d390..a9c417b 100644
--- a/drivers/staging/ccree/cc_lli_defs.h
+++ b/drivers/staging/ccree/cc_lli_defs.h
@@ -59,7 +59,7 @@ static inline void cc_lli_set_addr(u32 *lli_p, dma_addr_t 
addr)
lli_p[LLI_WORD0_OFFSET] = (addr & U32_MAX);
 #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
lli_p[LLI_WORD1_OFFSET] &= ~LLI_HADDR_MASK;
-   lli_p[LLI_WORD1_OFFSET] |= FIELD_PREP(LLI_HADDR_MASK, (addr >> 16));
+   lli_p[LLI_WORD1_OFFSET] |= FIELD_PREP(LLI_HADDR_MASK, (addr >> 32));
 #endif /* CONFIG_ARCH_DMA_ADDR_T_64BIT */
 }
 
-- 
2.7.4

Re: [PATCH] hw_random: Include device.h instead of declaring struct device

2017-10-30 Thread PrasannaKumar Muralidharan 
Hi Herbert,

On 30 October 2017 at 12:22, Herbert Xu  wrote:
> On Thu, Oct 26, 2017 at 07:12:08PM +0530, PrasannaKumar Muralidharan wrote:
>> Include linux/device.h instead of declaring struct device.
>>
>> Signed-off-by: PrasannaKumar Muralidharan 
>
> Nack.  We should not include a header file when a simple forward
> declaration is enough.

No issues.

Regards,
PrasannaKumar

Re: [PATCH 0/4] add CAAM DMA memcpy driver

2017-10-30 Thread Vinod Koul 
On Fri, Oct 27, 2017 at 12:20:32PM +, Horia Geantă wrote:
> On 10/27/2017 2:36 PM, Koul, Vinod wrote:
> >> On 10/26/2017 1:01 PM, Radu Alexe wrote:
> >>> This patch-set introduces a new DMA memcpy driver based on the DMA
> >>> capabilities of the CAAM crypto engine. Because of this dependency the
> >>> included commits target various parts of the kernel tree.
> >> I don't see the patches on any of the mail lists.
> >> If they are moderated, I would expect this to be mentioned in the
> >> MAINTAINERS file.
> >>
> >>>
> >>> Patch 1.
> >>> Since the CAAM DMA driver is a platform driver it is enabled by a new node
> >>> in the device tree. This commit adds documentation for the device tree
> >>> bindings.
> >>>
> >>> Patch 2.
> >>> This patch adds the "caam-dma" node in the fsl-ls1012a.dtsi file.
> >>>
> >>> Patch 3.
> >>> This commit adds various capabilities in the JR driver of the CAAM that is
> >>> used by the CAAM DMA driver.
> >>>
> >>> Patch 4.
> >>> Adds the CAAM DMA memcpy driver.
> >>>
> >>> Patch 1 and 3 should be merged by the crypto maintainers, patch 2 by
> >>> devicetree maintainers and patch 4 by the DMA maintainers.
> >> I would go with all the patches through the dmaengine tree.
> > 
> > Good call, but no one CCed dmaengine folks on this series!
> > 
> I see dmaeng...@vger.kernel.org Cc-ed on both cover letter and all four
> patches.
> It might be that the sender (Radu) is not subscribed and messages are
> awaiting moderators' approval.

I think vger lists are open, maybe sender has some issues with mail as they
are still not in any archives..

-- 
~Vinod

Re: [PATCH] hw_random: core: Reset user selected rng by writing "" to rng_current

2017-10-30 Thread Harald Freudenberger 
On 10/27/2017 07:04 PM, PrasannaKumar Muralidharan wrote:
> User is able to select a chosen rng by writing its name to rng_current
> but there is no way to reset it without unbinding the rng. Let user
> write "" to rng_current and delesect the chosen rng.
>
> Signed-off-by: PrasannaKumar Muralidharan 
> ---
>  drivers/char/hw_random/core.c | 51 
> +++
>  1 file changed, 32 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index 9701ac7..be03024 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -292,26 +292,48 @@ static struct miscdevice rng_miscdev = {
>   .groups = rng_dev_groups,
>  };
>
> +static int enable_best_rng(void)
> +{
> + int ret = -ENODEV;
> +
> + BUG_ON(!mutex_is_locked(_mutex));
> +
> + /* rng_list is sorted by quality, use the best (=first) one */
> + if (!list_empty(_list)) {
> + struct hwrng *new_rng;
> +
> + new_rng = list_entry(rng_list.next, struct hwrng, list);
> + ret = ((new_rng == current_rng) ? 0 : set_current_rng(new_rng));
> + if (!ret)
> + cur_rng_set_by_user = 0;
> + }
> +
> + return ret;
> +}
> +
>  static ssize_t hwrng_attr_current_store(struct device *dev,
>   struct device_attribute *attr,
>   const char *buf, size_t len)
>  {
> - int err;
> + int err = -ENODEV;
Two lines later err is assigned the return value of mutex_lock_interruptible().
So the -ENODEV value assignment does nothing.
>   struct hwrng *rng;
>
>   err = mutex_lock_interruptible(_mutex);
>   if (err)
>   return -ERESTARTSYS;
> - err = -ENODEV;
> - list_for_each_entry(rng, _list, list) {
> - if (sysfs_streq(rng->name, buf)) {
> - err = 0;
> - cur_rng_set_by_user = 1;
> - if (rng != current_rng)
> +
> + if (sysfs_streq(buf, "")) {
> + err = enable_best_rng();
> + } else {
> + list_for_each_entry(rng, _list, list) {
> + if (sysfs_streq(rng->name, buf)) {
> + cur_rng_set_by_user = 1;
>   err = set_current_rng(rng);
> - break;
> + break;
> + }
>   }
>   }
> +
>   mutex_unlock(_mutex);
>
>   return err ? : len;
> @@ -493,17 +515,8 @@ void hwrng_unregister(struct hwrng *rng)
>   mutex_lock(_mutex);
>
>   list_del(>list);
> - if (current_rng == rng) {
> - drop_current_rng();
> - cur_rng_set_by_user = 0;
> - /* rng_list is sorted by quality, use the best (=first) one */
> - if (!list_empty(_list)) {
> - struct hwrng *new_rng;
> -
> - new_rng = list_entry(rng_list.next, struct hwrng, list);
> - set_current_rng(new_rng);
> - }
> - }
> + if (current_rng == rng)
> + enable_best_rng();
>
>   if (list_empty(_list)) {
>   mutex_unlock(_mutex);
looks like for me.
reviewed-by: Harald Freudenberger

[PATCH RESEND 4/4] dma: caam: add dma memcpy driver

2017-10-30 Thread Horia Geantă 
From: Radu Alexe 

This module introduces a memcpy DMA driver based on the DMA capabilities
of the CAAM hardware block. CAAM DMA is a platform driver that is only
probed if the device is defined in the device tree. The driver creates
a DMA channel for each JR of the CAAM. This introduces a dependency on
the JR driver. Therefore a defering mechanism was used to ensure that
the CAAM DMA driver is probed only after the JR driver.

Signed-off-by: Radu Alexe 
Signed-off-by: Tudor Ambarus 
Signed-off-by: Rajiv Vishwakarma 
---
 drivers/dma/Kconfig|  17 ++
 drivers/dma/Makefile   |   1 +
 drivers/dma/caam_dma.c | 444 +
 3 files changed, 462 insertions(+)
 create mode 100644 drivers/dma/caam_dma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index fadc4d8783bd..0df48307dac1 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -600,6 +600,23 @@ config ZX_DMA
help
  Support the DMA engine for ZTE ZX family platform devices.
 
+config CRYPTO_DEV_FSL_CAAM_DMA
+   tristate "CAAM DMA engine support"
+   depends on CRYPTO_DEV_FSL_CAAM_JR
+   default y
+   select DMA_ENGINE
+   select ASYNC_CORE
+   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
+   help
+ Selecting this will offload the DMA operations for users of
+ the scatter gather memcopy API to the CAAM via job rings. The
+ CAAM is a hardware module that provides hardware acceleration to
+ cryptographic operations. It has a built-in DMA controller that can
+ be programmed to read/write cryptographic data. This module defines
+ a DMA driver that uses the DMA capabilities of the CAAM.
+
+ To compile this as a module, choose M here: the module
+ will be called caam_dma.
 
 # driver files
 source "drivers/dma/bestcomm/Kconfig"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index f08f8de1b567..37563454d624 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_TI_EDMA) += edma.o
 obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 obj-$(CONFIG_ZX_DMA) += zx_dma.o
 obj-$(CONFIG_ST_FDMA) += st_fdma.o
+obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_DMA) += caam_dma.o
 
 obj-y += qcom/
 obj-y += xilinx/
diff --git a/drivers/dma/caam_dma.c b/drivers/dma/caam_dma.c
new file mode 100644
index ..dfd5409864b0
--- /dev/null
+++ b/drivers/dma/caam_dma.c
@@ -0,0 +1,444 @@
+/*
+ * caam support for SG DMA
+ *
+ * Copyright 2016 Freescale Semiconductor, Inc
+ * Copyright 2017 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "dmaengine.h"
+
+#include "../crypto/caam/regs.h"
+#include "../crypto/caam/jr.h"
+#include "../crypto/caam/error.h"
+#include "../crypto/caam/intern.h"
+#include "../crypto/caam/desc_constr.h"
+
+#define DESC_DMA_MEMCPY_LEN((CAAM_DESC_BYTES_MAX - DESC_JOB_IO_LEN) / \
+CAAM_CMD_SZ)
+
+/* This is max chunk size of a DMA transfer. If a buffer is larger than this
+ * value it is internally broken into chunks of max CAAM_DMA_CHUNK_SIZE bytes
+ * and for each chunk a DMA transfer request is issued.
+ * This value is the largest number on 16 bits that is a multiple of 256 bytes
+ * (the largest configurable CAAM DMA burst size).
+ */
+#define CAAM_DMA_CHUNK_SIZE65280
+
+struct caam_dma_sh_desc {
+   u32 desc[DESC_DMA_MEMCPY_LEN] cacheline_aligned;
+   dma_addr_t desc_dma;
+};
+
+/* caam dma extended descriptor */
+struct caam_dma_edesc {
+   struct dma_async_tx_descriptor async_tx;
+   struct list_head node;
+   struct caam_dma_ctx *ctx;
+   dma_addr_t src_dma;
+   dma_addr_t dst_dma;
+   unsigned int src_len;
+   unsigned int dst_len;
+   u32 jd[] cacheline_aligned;
+};
+
+/*
+ * caam_dma_ctx - per jr/channel context
+ * @chan: dma channel used by async_tx API
+ * @node: list_head used to attach to the global dma_ctx_list
+ * @jrdev: Job Ring device
+ * @submit_q: queue of pending (submitted, but not enqueued) jobs
+ * @done_not_acked: jobs that have been completed by jr, but maybe not acked
+ * @edesc_lock: protects extended descriptor
+ */
+struct caam_dma_ctx {
+   struct dma_chan chan;
+   struct list_head node;
+   struct device *jrdev;
+   struct list_head submit_q;
+   struct list_head done_not_acked;
+   spinlock_t edesc_lock;
+};
+
+static struct dma_device *dma_dev;
+static struct caam_dma_sh_desc *dma_sh_desc;
+static LIST_HEAD(dma_ctx_list);
+
+static dma_cookie_t caam_dma_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+   struct caam_dma_edesc *edesc = NULL;
+   struct caam_dma_ctx *ctx = NULL;
+   dma_cookie_t cookie;
+
+   edesc = container_of(tx, struct caam_dma_edesc, async_tx);
+   ctx = container_of(tx->chan, struct caam_dma_ctx, chan);
+
+   spin_lock_bh(>edesc_lock);
+
+

[PATCH RESEND 2/4] arm64: dts: ls1012a: add caam-dma node

2017-10-30 Thread Horia Geantă 
From: Radu Alexe 

Signed-off-by: Radu Alexe 
---
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index df83915d6ea6..f92ecf381cb1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -197,6 +197,12 @@
interrupts = ;
};
 
+   caam-dma {
+   compatible = "fsl,sec-v5.4-dma",
+"fsl,sec-v5.0-dma",
+"fsl,sec-v4.0-dma";
+   };
+
rtic@6 {
compatible = "fsl,sec-v5.4-rtic",
 "fsl,sec-v5.0-rtic",
-- 
2.14.2.606.g7451fcd

[PATCH RESEND 0/4] add CAAM DMA memcpy driver

2017-10-30 Thread Horia Geantă 
From: Radu Alexe 

This patch-set introduces a new DMA memcpy driver based on the DMA
capabilities of the CAAM crypto engine. Because of this dependency the
included commits target various parts of the kernel tree.

Patch 1.
Since the CAAM DMA driver is a platform driver it is enabled by a new node
in the device tree. This commit adds documentation for the device tree
bindings.

Patch 2.
This patch adds the "caam-dma" node in the fsl-ls1012a.dtsi file.

Patch 3.
This commit adds various capabilities in the JR driver of the CAAM that is
used by the CAAM DMA driver.

Patch 4.
Adds the CAAM DMA memcpy driver.

Patch 1 and 3 should be ack-ed by the crypto maintainers, patch 2 by
devicetree maintainers and patch 4 by the DMA maintainers.
The intent is to go withh all the patches through the dmaengine tree.

Radu Alexe (4):
  crypto: caam: add caam-dma node to SEC4.0 device tree binding
  arm64: dts: ls1012a: add caam-dma node
  crypto: caam: add functionality used by the caam_dma driver
  dma: caam: add dma memcpy driver

 .../devicetree/bindings/crypto/fsl-sec4.txt|  21 +
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi |   6 +
 drivers/crypto/caam/desc.h |   3 +
 drivers/crypto/caam/jr.c   |  42 ++
 drivers/crypto/caam/jr.h   |   2 +
 drivers/dma/Kconfig|  17 +
 drivers/dma/Makefile   |   1 +
 drivers/dma/caam_dma.c | 444 +
 8 files changed, 536 insertions(+)
 create mode 100644 drivers/dma/caam_dma.c

-- 
2.14.2.606.g7451fcd

[PATCH RESEND 1/4] crypto: caam: add caam-dma node to SEC4.0 device tree binding

2017-10-30 Thread Horia Geantă 
From: Radu Alexe 

Signed-off-by: Radu Alexe 
---
 .../devicetree/bindings/crypto/fsl-sec4.txt | 21 +
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt 
b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
index 7aef0eae58d4..97b37c15d793 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -6,6 +6,7 @@ Copyright (C) 2008-2011 Freescale Semiconductor Inc.
-Overview
-SEC 4 Node
-Job Ring Node
+   -CAAM DMA Node
-Run Time Integrity Check (RTIC) Node
-Run Time Integrity Check (RTIC) Memory Node
-Secure Non-Volatile Storage (SNVS) Node
@@ -215,6 +216,26 @@ EXAMPLE
interrupts = <88 2>;
};
 
+=
+CAAM DMA Node
+
+Child node of the crypto node that enables the use of the DMA capabilities
+of the CAAM by a stand-alone driver. The only required property is the
+"compatible" property. All the other properties are determined from
+the job rings on which the CAAM DMA driver depends (ex: the number of
+dma-channels is equal to the number of defined job rings).
+
+  - compatible
+  Usage: required
+  Value type: 
+  Definition: Must include "fsl,sec-v4.0-dma"
+
+EXAMPLE
+  caam-dma {
+compatible = "fsl,sec-v5.4-dma",
+ "fsl,sec-v5.0-dma",
+ "fsl,sec-v4.0-dma";
+  }
 
 =
 Run Time Integrity Check (RTIC) Node
-- 
2.14.2.606.g7451fcd

[PATCH RESEND 3/4] crypto: caam: add functionality used by the caam_dma driver

2017-10-30 Thread Horia Geantă 
From: Radu Alexe 

The caam_dma is a memcpy DMA driver based on the DMA functionality of
the CAAM hardware block. It creates a DMA channel for each JR of the
CAAM. This patch adds functionality that is used by the caam_dma that is
not yet part of the JR driver.

Signed-off-by: Radu Alexe 
---
 drivers/crypto/caam/desc.h |  3 +++
 drivers/crypto/caam/jr.c   | 42 ++
 drivers/crypto/caam/jr.h   |  2 ++
 3 files changed, 47 insertions(+)

diff --git a/drivers/crypto/caam/desc.h b/drivers/crypto/caam/desc.h
index 2e6766a1573f..f03221d2468a 100644
--- a/drivers/crypto/caam/desc.h
+++ b/drivers/crypto/caam/desc.h
@@ -354,6 +354,7 @@
 #define FIFOLD_TYPE_PK_N   (0x08 << FIFOLD_TYPE_SHIFT)
 #define FIFOLD_TYPE_PK_A   (0x0c << FIFOLD_TYPE_SHIFT)
 #define FIFOLD_TYPE_PK_B   (0x0d << FIFOLD_TYPE_SHIFT)
+#define FIFOLD_TYPE_IFIFO  (0x0f << FIFOLD_TYPE_SHIFT)
 
 /* Other types. Need to OR in last/flush bits as desired */
 #define FIFOLD_TYPE_MSG_MASK   (0x38 << FIFOLD_TYPE_SHIFT)
@@ -407,6 +408,7 @@
 #define FIFOST_TYPE_MESSAGE_DATA (0x30 << FIFOST_TYPE_SHIFT)
 #define FIFOST_TYPE_RNGSTORE(0x34 << FIFOST_TYPE_SHIFT)
 #define FIFOST_TYPE_RNGFIFO (0x35 << FIFOST_TYPE_SHIFT)
+#define FIFOST_TYPE_METADATA(0x3e << FIFOST_TYPE_SHIFT)
 #define FIFOST_TYPE_SKIP(0x3f << FIFOST_TYPE_SHIFT)
 
 /*
@@ -1443,6 +1445,7 @@
 #define MATH_SRC1_INFIFO   (0x0a << MATH_SRC1_SHIFT)
 #define MATH_SRC1_OUTFIFO  (0x0b << MATH_SRC1_SHIFT)
 #define MATH_SRC1_ONE  (0x0c << MATH_SRC1_SHIFT)
+#define MATH_SRC1_ZERO (0x0f << MATH_SRC1_SHIFT)
 
 /* Destination selectors */
 #define MATH_DEST_SHIFT8
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index d258953ff488..00e87094588d 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -23,6 +23,14 @@ struct jr_driver_data {
 
 static struct jr_driver_data driver_data;
 
+static int jr_driver_probed;
+
+int caam_jr_driver_probed(void)
+{
+   return jr_driver_probed;
+}
+EXPORT_SYMBOL(caam_jr_driver_probed);
+
 static int caam_reset_hw_jr(struct device *dev)
 {
struct caam_drv_private_jr *jrp = dev_get_drvdata(dev);
@@ -119,6 +127,8 @@ static int caam_jr_remove(struct platform_device *pdev)
dev_err(jrdev, "Failed to shut down job ring\n");
irq_dispose_mapping(jrpriv->irq);
 
+   jr_driver_probed--;
+
return ret;
 }
 
@@ -280,6 +290,36 @@ struct device *caam_jr_alloc(void)
 }
 EXPORT_SYMBOL(caam_jr_alloc);
 
+/**
+ * caam_jridx_alloc() - Alloc a specific job ring based on its index.
+ *
+ * returns :  pointer to the newly allocated physical
+ *   JobR dev can be written to if successful.
+ **/
+struct device *caam_jridx_alloc(int idx)
+{
+   struct caam_drv_private_jr *jrpriv;
+   struct device *dev = ERR_PTR(-ENODEV);
+
+   spin_lock(_data.jr_alloc_lock);
+
+   if (list_empty(_data.jr_list))
+   goto end;
+
+   list_for_each_entry(jrpriv, _data.jr_list, list_node) {
+   if (jrpriv->ridx == idx) {
+   atomic_inc(>tfm_count);
+   dev = jrpriv->dev;
+   break;
+   }
+   }
+
+end:
+   spin_unlock(_data.jr_alloc_lock);
+   return dev;
+}
+EXPORT_SYMBOL(caam_jridx_alloc);
+
 /**
  * caam_jr_free() - Free the Job Ring
  * @rdev - points to the dev that identifies the Job ring to
@@ -538,6 +578,8 @@ static int caam_jr_probe(struct platform_device *pdev)
 
atomic_set(>tfm_count, 0);
 
+   jr_driver_probed++;
+
return 0;
 }
 
diff --git a/drivers/crypto/caam/jr.h b/drivers/crypto/caam/jr.h
index 97113a6d6c58..ee4d31c9aeb8 100644
--- a/drivers/crypto/caam/jr.h
+++ b/drivers/crypto/caam/jr.h
@@ -8,7 +8,9 @@
 #define JR_H
 
 /* Prototypes for backend-level services exposed to APIs */
+int caam_jr_driver_probed(void);
 struct device *caam_jr_alloc(void);
+struct device *caam_jridx_alloc(int idx);
 void caam_jr_free(struct device *rdev);
 int caam_jr_enqueue(struct device *dev, u32 *desc,
void (*cbk)(struct device *dev, u32 *desc, u32 status,
-- 
2.14.2.606.g7451fcd

Re: [PATCH] hw_random: core: Reset user selected rng by writing "" to rng_current

2017-10-30 Thread PrasannaKumar Muralidharan 
Hi Harald,

On 30 October 2017 at 18:58, Harald Freudenberger
 wrote:
> On 10/27/2017 07:04 PM, PrasannaKumar Muralidharan wrote:
>> User is able to select a chosen rng by writing its name to rng_current
>> but there is no way to reset it without unbinding the rng. Let user
>> write "" to rng_current and delesect the chosen rng.
>>
>> Signed-off-by: PrasannaKumar Muralidharan 
>> ---
>>  drivers/char/hw_random/core.c | 51 
>> +++
>>  1 file changed, 32 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
>> index 9701ac7..be03024 100644
>> --- a/drivers/char/hw_random/core.c
>> +++ b/drivers/char/hw_random/core.c
>> @@ -292,26 +292,48 @@ static struct miscdevice rng_miscdev = {
>>   .groups = rng_dev_groups,
>>  };
>>
>> +static int enable_best_rng(void)
>> +{
>> + int ret = -ENODEV;
>> +
>> + BUG_ON(!mutex_is_locked(_mutex));
>> +
>> + /* rng_list is sorted by quality, use the best (=first) one */
>> + if (!list_empty(_list)) {
>> + struct hwrng *new_rng;
>> +
>> + new_rng = list_entry(rng_list.next, struct hwrng, list);
>> + ret = ((new_rng == current_rng) ? 0 : 
>> set_current_rng(new_rng));
>> + if (!ret)
>> + cur_rng_set_by_user = 0;
>> + }
>> +
>> + return ret;
>> +}
>> +
>>  static ssize_t hwrng_attr_current_store(struct device *dev,
>>   struct device_attribute *attr,
>>   const char *buf, size_t len)
>>  {
>> - int err;
>> + int err = -ENODEV;
> Two lines later err is assigned the return value of 
> mutex_lock_interruptible().
> So the -ENODEV value assignment does nothing.

Indeed true. Will change this when I make a v2.

I am even thinking if it makes sense to return error when user writes
"" to rng_current and there is no rng device registered. I think
returning 0 should be fine.

>>   struct hwrng *rng;
>>
>>   err = mutex_lock_interruptible(_mutex);
>>   if (err)
>>   return -ERESTARTSYS;
>> - err = -ENODEV;
>> - list_for_each_entry(rng, _list, list) {
>> - if (sysfs_streq(rng->name, buf)) {
>> - err = 0;
>> - cur_rng_set_by_user = 1;
>> - if (rng != current_rng)
>> +
>> + if (sysfs_streq(buf, "")) {
>> + err = enable_best_rng();
>> + } else {
>> + list_for_each_entry(rng, _list, list) {
>> + if (sysfs_streq(rng->name, buf)) {
>> + cur_rng_set_by_user = 1;
>>   err = set_current_rng(rng);
>> - break;
>> + break;
>> + }
>>   }
>>   }
>> +
>>   mutex_unlock(_mutex);
>>
>>   return err ? : len;
>> @@ -493,17 +515,8 @@ void hwrng_unregister(struct hwrng *rng)
>>   mutex_lock(_mutex);
>>
>>   list_del(>list);
>> - if (current_rng == rng) {
>> - drop_current_rng();
>> - cur_rng_set_by_user = 0;
>> - /* rng_list is sorted by quality, use the best (=first) one */
>> - if (!list_empty(_list)) {
>> - struct hwrng *new_rng;
>> -
>> - new_rng = list_entry(rng_list.next, struct hwrng, 
>> list);
>> - set_current_rng(new_rng);
>> - }
>> - }
>> + if (current_rng == rng)
>> + enable_best_rng();
>>
>>   if (list_empty(_list)) {
>>   mutex_unlock(_mutex);
> looks like for me.
> reviewed-by: Harald Freudenberger 
>

Thank you.

Thanks,
PrasannaKumar

Re: [PATCH] hw_random: core: Reset user selected rng by writing "" to rng_current

2017-10-30 Thread PrasannaKumar Muralidharan 
Hi Harald,

On 30 October 2017 at 13:40, Harald Freudenberger
 wrote:
> That's a really good idea. I also thought about something like that.

Do you mind reviewing the code?

Thanks,
PrasannaKumar

Re: [PATCH] hw_random: core: Remove unnecessary new line in MODULE_PARM_DESC

2017-10-30 Thread PrasannaKumar Muralidharan 
Hi Herbert,

On 30 October 2017 at 12:23, Herbert Xu  wrote:
> On Thu, Oct 26, 2017 at 10:00:29PM +0530, PrasannaKumar Muralidharan wrote:
>> While using MODULE_PARM_DESC there is a new line which is not required.
>> Remove it.
>>
>> Signed-off-by: PrasannaKumar Muralidharan 
>
> Please stop sending pointless patches like this.

Okay.

Regards,
PrasannaKumar

Re: [PATCH RESEND 1/4] crypto: caam: add caam-dma node to SEC4.0 device tree binding

2017-10-30 Thread Kim Phillips 
On Mon, 30 Oct 2017 15:46:51 +0200
Horia Geantă  wrote:

> +=
> +CAAM DMA Node
> +
> +Child node of the crypto node that enables the use of the DMA 
> capabilities
> +of the CAAM by a stand-alone driver. The only required property is the
> +"compatible" property. All the other properties are determined from
> +the job rings on which the CAAM DMA driver depends (ex: the number of
> +dma-channels is equal to the number of defined job rings).
> +
> +  - compatible
> +  Usage: required
> +  Value type: 
> +  Definition: Must include "fsl,sec-v4.0-dma"
> +
> +EXAMPLE
> +  caam-dma {
> +compatible = "fsl,sec-v5.4-dma",
> + "fsl,sec-v5.0-dma",
> + "fsl,sec-v4.0-dma";
> +  }

If this isn't describing an aspect of the hardware, then what is it
doing in the device tree?

Kim

Re: [PATCH] hw_random: core: Reset user selected rng by writing "" to rng_current

2017-10-30 Thread Harald Freudenberger 
On 10/27/2017 07:04 PM, PrasannaKumar Muralidharan wrote:
> User is able to select a chosen rng by writing its name to rng_current
> but there is no way to reset it without unbinding the rng. Let user
> write "" to rng_current and delesect the chosen rng.
>
> Signed-off-by: PrasannaKumar Muralidharan 
> ---
>  drivers/char/hw_random/core.c | 51 
> +++
>  1 file changed, 32 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index 9701ac7..be03024 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -292,26 +292,48 @@ static struct miscdevice rng_miscdev = {
>   .groups = rng_dev_groups,
>  };
>
> +static int enable_best_rng(void)
> +{
> + int ret = -ENODEV;
> +
> + BUG_ON(!mutex_is_locked(_mutex));
> +
> + /* rng_list is sorted by quality, use the best (=first) one */
> + if (!list_empty(_list)) {
> + struct hwrng *new_rng;
> +
> + new_rng = list_entry(rng_list.next, struct hwrng, list);
> + ret = ((new_rng == current_rng) ? 0 : set_current_rng(new_rng));
> + if (!ret)
> + cur_rng_set_by_user = 0;
> + }
> +
> + return ret;
> +}
> +
>  static ssize_t hwrng_attr_current_store(struct device *dev,
>   struct device_attribute *attr,
>   const char *buf, size_t len)
>  {
> - int err;
> + int err = -ENODEV;
>   struct hwrng *rng;
>
>   err = mutex_lock_interruptible(_mutex);
>   if (err)
>   return -ERESTARTSYS;
> - err = -ENODEV;
> - list_for_each_entry(rng, _list, list) {
> - if (sysfs_streq(rng->name, buf)) {
> - err = 0;
> - cur_rng_set_by_user = 1;
> - if (rng != current_rng)
> +
> + if (sysfs_streq(buf, "")) {
> + err = enable_best_rng();
> + } else {
> + list_for_each_entry(rng, _list, list) {
> + if (sysfs_streq(rng->name, buf)) {
> + cur_rng_set_by_user = 1;
>   err = set_current_rng(rng);
> - break;
> + break;
> + }
>   }
>   }
> +
>   mutex_unlock(_mutex);
>
>   return err ? : len;
> @@ -493,17 +515,8 @@ void hwrng_unregister(struct hwrng *rng)
>   mutex_lock(_mutex);
>
>   list_del(>list);
> - if (current_rng == rng) {
> - drop_current_rng();
> - cur_rng_set_by_user = 0;
> - /* rng_list is sorted by quality, use the best (=first) one */
> - if (!list_empty(_list)) {
> - struct hwrng *new_rng;
> -
> - new_rng = list_entry(rng_list.next, struct hwrng, list);
> - set_current_rng(new_rng);
> - }
> - }
> + if (current_rng == rng)
> + enable_best_rng();
>
>   if (list_empty(_list)) {
>   mutex_unlock(_mutex);
That's a really good idea. I also thought about something like that.
regards
Harald Freudenberger

Re: [PATCH v2 6/8] scsi/ipr: Use sgl_alloc_order() and sgl_free_order()

2017-10-30 Thread Brian King 
On 10/30/2017 03:37 PM, Bart Van Assche wrote:
> On Wed, 2017-10-18 at 15:57 -0500, Brian King wrote:
>> On 10/17/2017 01:19 AM, Hannes Reinecke wrote:
>>> On 10/17/2017 12:49 AM, Bart Van Assche wrote:
 [ ... ]
>>>
>>> Not sure if this is a valid conversion.
>>> Originally the driver would allocate a single buffer; with this buffer
>>> we have two distinct buffers.
>>> Given that this is used to download the microcode I'm not sure if this
>>> isn't a hardware-dependent structure which requires a single buffer
>>> including the sglist.
>>> Brian, can you shed some light here?
>>
>> The struct ipr_sglist is not a hardware defined data structure, so on initial
>> glance, this should be OK. I'll load it up and give it a try to make sure
>> it doesn't break code download.
> 
> Hello Brian,
> 
> Have you already obtained any test results?

Bart,

Yes. I tried this out on an ipr adapter and it looks fine.

Acked-by: Brian King 

Thanks,

Brian

-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

Re: [PATCH v2 6/8] scsi/ipr: Use sgl_alloc_order() and sgl_free_order()

2017-10-30 Thread Bart Van Assche 
On Wed, 2017-10-18 at 15:57 -0500, Brian King wrote:
> On 10/17/2017 01:19 AM, Hannes Reinecke wrote:
> > On 10/17/2017 12:49 AM, Bart Van Assche wrote:
> > > [ ... ]
> > 
> > Not sure if this is a valid conversion.
> > Originally the driver would allocate a single buffer; with this buffer
> > we have two distinct buffers.
> > Given that this is used to download the microcode I'm not sure if this
> > isn't a hardware-dependent structure which requires a single buffer
> > including the sglist.
> > Brian, can you shed some light here?
> 
> The struct ipr_sglist is not a hardware defined data structure, so on initial
> glance, this should be OK. I'll load it up and give it a try to make sure
> it doesn't break code download.

Hello Brian,

Have you already obtained any test results?

Thanks,

Bart.

Re: [Part2 PATCH v6.1 16/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-30 Thread Brijesh Singh 


On 10/30/17 12:57 PM, Borislav Petkov wrote:
> On Mon, Oct 30, 2017 at 12:49:14PM -0500, Brijesh Singh wrote:
>> If the buffer is allocated on the stack then there is no guarantee that
> static global is not allocated on the stack.

Okay, Just tried static global with CONFIG_VMAP_STACK=y and I am getting
wrong physical address with __pa. PSP command fails with error code
"INVALID_ADDRESS". The same thing works fine with kmalloc() buffer.

>> I can certainly move the allocation outside, but then it may increase the
>> code size in other functions. If its not a big deal then I would prefer to
>> keep what we have.
> Avoiding repeated k*alloc calls is always a good thing. Actually kmalloc-ing 
> 20
> bytes each time sounds like it is not worth the calling overhead to me.
>

To avoid repeated k*alloc calls, I could devm_kzalloc() these variable 
during sev_init() and reuse them when needed.

Re: [Part2 PATCH v6.1 16/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-30 Thread Brijesh Singh 



On 10/30/2017 12:21 PM, Borislav Petkov wrote:
...



Useless forward declarations.



Actually its helpful in other patches. I was trying to avoid making too 
many code movement in other patches to eliminate the forward 
declarations. I guess I can fix in v7.




  static struct psp_device *psp_alloc_struct(struct sp_device *sp)
  {
struct device *dev = sp->dev;


...


+static int sev_do_cmd_locked(int cmd, void *data, int *psp_ret)


You can use the "__" prefix to denote that it is a lower-level helper:

__sev_do_cmd
__sev_do_cmd_locked

Ditto for the other locked functions.


noted


...


+static int sev_platform_init_locked(struct sev_data_init *data, int *error)
+{
+   struct psp_device *psp = psp_master;
+   struct sev_data_init *input = NULL;
+   int rc = 0;
+
+   if (!psp)
+   return -ENODEV;
+
+   if (psp->sev_state == SEV_STATE_INIT)
+   return 0;
+
+   if (!data) {
+   input = kzalloc(sizeof(*input), GFP_KERNEL);
+   if (!input)
+   return -ENOMEM;
+
+   data = input;
+   }


You can do the allocation in the enclosing function, outside of the
critical region so that you can keep it shorter.

Or even better: if you're going to synchronize the commands with a
mutex, you can define a static struct sev_data_init input in this file
which you always hand in and then you can save yourself the kmalloc
calls.



If the buffer is allocated on the stack then there is no guarantee that 
__pa() will gives us a valid physical address. IIRC, when 
CONFIG_VMAP_STACK=y then stack space is mapped similar to vmalloc'd 
storage and __pa() will not work.


Since we need to pass the physical address to PSP hence variable 
allocated on the stack will not work.


I can certainly move the allocation outside, but then it may increase 
the code size in other functions. If its not a big deal then I would 
prefer to keep what we have.



...

+
+int sev_platform_shutdown(int *error)
+{
+   if (error)
+   *error = 0;
+
+   return 0;
+}


I'm guessing that that's just bare-bones and it will get filled up in
the next patches. Otherwise it looks pretty useless.



Well, we are not expanding in other patches. I was also debating on what 
to do with this function. Since we need sev_platform_init() hence it 
made sense to add sev_platform_shutdown() as well. If we add the 
function then I wanted to make sure that we set the *error = SUCCESS so 
that caller knows that function succeeded.




If it is just to block the user from sending SHUTDOWN to the PSP
master, just do that in the ioctl directly - no need to call some empty
functions.



The function is not used by userspace ioctl, its used by kvm drv when it 
launch/terminates the SEV guest.


-Brijesh

Re: [Part2 PATCH v6.1 16/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-30 Thread Borislav Petkov 
On Mon, Oct 30, 2017 at 12:49:14PM -0500, Brijesh Singh wrote:
> If the buffer is allocated on the stack then there is no guarantee that

static global is not allocated on the stack.

> I can certainly move the allocation outside, but then it may increase the
> code size in other functions. If its not a big deal then I would prefer to
> keep what we have.

Avoiding repeated k*alloc calls is always a good thing. Actually kmalloc-ing 20
bytes each time sounds like it is not worth the calling overhead to me.

> The function is not used by userspace ioctl, its used by kvm drv when it
> launch/terminates the SEV guest.

Just do that directly in the ioctl instead of having a dumb function.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [Part2 PATCH v6.1 16/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-30 Thread Borislav Petkov 
On Sun, Oct 29, 2017 at 03:48:25PM -0500, Brijesh Singh wrote:
> AMD's new Secure Encrypted Virtualization (SEV) feature allows the
> memory contents of virtual machines to be transparently encrypted with a
> key unique to the VM. The programming and management of the encryption
> keys are handled by the AMD Secure Processor (AMD-SP) which exposes the
> commands for these tasks. The complete spec is available at:

...

> Changes since v6:
>  * Add functions to init and shutdown firmware during modprobe
>  * Add sev_state variable in psp_device to keep track of the INIT and SHUTDOWN
>state
>  * Don't allow caller to shutdown the FW because SHUTDOWN will be done during
>the module removal.
>  * Drop the fw_init_mutex and init_refcount because we no longer allow apps to
>INIT and UINIT the platform

Yes, it definitely looks much better this way. Thanks for doing that!

> 
>  drivers/crypto/ccp/psp-dev.c | 360 
> +++
>  drivers/crypto/ccp/psp-dev.h |  22 +++
>  drivers/crypto/ccp/sp-dev.c  |   9 ++
>  drivers/crypto/ccp/sp-dev.h  |   4 +
>  include/linux/psp-sev.h  | 158 +++
>  5 files changed, 553 insertions(+)
> 
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index b5789f878560..060f57ac08b3 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -26,6 +26,15 @@
>  #include "sp-dev.h"
>  #include "psp-dev.h"
>  
> +#define DEVICE_NAME  "sev"
> +
> +static DEFINE_MUTEX(sev_cmd_mutex);
> +static struct sev_misc_dev *misc_dev;
> +static struct psp_device *psp_master;
> +
> +static int sev_platform_shutdown_locked(int *error);
> +static int sev_platform_init_locked(struct sev_data_init *data, int *error);

Useless forward declarations.

>  static struct psp_device *psp_alloc_struct(struct sp_device *sp)
>  {
>   struct device *dev = sp->dev;

...

> +static int sev_do_cmd_locked(int cmd, void *data, int *psp_ret)

You can use the "__" prefix to denote that it is a lower-level helper:

__sev_do_cmd
__sev_do_cmd_locked

Ditto for the other locked functions.

> + struct psp_device *psp = psp_master;
> + unsigned int phys_lsb, phys_msb;
> + unsigned int reg, ret = 0;
> +
> + if (!psp)
> + return -ENODEV;
> +
> + /* Get the physical address of the command buffer */
> + phys_lsb = data ? lower_32_bits(__psp_pa(data)) : 0;
> + phys_msb = data ? upper_32_bits(__psp_pa(data)) : 0;
> +
> + dev_dbg(psp->dev, "sev command id %#x buffer 0x%08x%08x\n",
> + cmd, phys_msb, phys_lsb);
> +
> + print_hex_dump_debug("(in):  ", DUMP_PREFIX_OFFSET, 16, 2, data,
> +  sev_cmd_buffer_len(cmd), false);
> +
> + iowrite32(phys_lsb, psp->io_regs + PSP_CMDBUFF_ADDR_LO);
> + iowrite32(phys_msb, psp->io_regs + PSP_CMDBUFF_ADDR_HI);
> +
> + reg = cmd;
> + reg <<= PSP_CMDRESP_CMD_SHIFT;
> + reg |= PSP_CMDRESP_IOC;
> + iowrite32(reg, psp->io_regs + PSP_CMDRESP);
> +
> + /* wait for command completion */
> + sev_wait_cmd_ioc(psp, );
> +
> + if (psp_ret)
> + *psp_ret = reg & PSP_CMDRESP_ERR_MASK;
> +
> + if (reg & PSP_CMDRESP_ERR_MASK) {
> + dev_dbg(psp->dev, "sev command %#x failed (%#010x)\n",
> + cmd, reg & PSP_CMDRESP_ERR_MASK);
> + ret = -EIO;
> + }
> +
> + print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data,
> +  sev_cmd_buffer_len(cmd), false);
> +
> + return ret;
> +}

...

> +static int sev_platform_init_locked(struct sev_data_init *data, int *error)
> +{
> + struct psp_device *psp = psp_master;
> + struct sev_data_init *input = NULL;
> + int rc = 0;
> +
> + if (!psp)
> + return -ENODEV;
> +
> + if (psp->sev_state == SEV_STATE_INIT)
> + return 0;
> +
> + if (!data) {
> + input = kzalloc(sizeof(*input), GFP_KERNEL);
> + if (!input)
> + return -ENOMEM;
> +
> + data = input;
> + }

You can do the allocation in the enclosing function, outside of the
critical region so that you can keep it shorter.

Or even better: if you're going to synchronize the commands with a
mutex, you can define a static struct sev_data_init input in this file
which you always hand in and then you can save yourself the kmalloc
calls.

> +
> + rc = sev_do_cmd_locked(SEV_CMD_INIT, data, error);
> + if (rc)
> + goto e_free;
> +
> + psp->sev_state = SEV_STATE_INIT;
> + dev_dbg(psp->dev, "SEV firmware intialized\n");

WARNING: 'intialized' may be misspelled - perhaps 'initialized'?
#254: FILE: drivers/crypto/ccp/psp-dev.c:215:
+   dev_dbg(psp->dev, "SEV firmware intialized\n");

WARNING: space prohibited between function name and open parenthesis '('
#445: FILE: drivers/crypto/ccp/psp-dev.c:440:
+   data = kzalloc(sizeof (*data), GFP_KERNEL);

Ok, tell me: how many times do I

Re: [PATCH] crypto: AF_ALG - remove locking in async callback

2017-10-30 Thread Romain Izard 
2017-10-29 21:39 GMT+01:00 Stephan Müller :
> Am Mittwoch, 25. Oktober 2017, 17:26:31 CET schrieb Romain Izard:
>
> Hi Romain,
>
> the patch below should cover the issue you see. Would you mind testing it?
>
> Thanks
> Stephan
>
> ---8<---
>
> The code paths protected by the socket-lock do not use or modify the
> socket in a non-atomic fashion. The actions pertaining the socket do not
> even need to be handled as an atomic operation. Thus, the socket-lock
> can be safely ignored.
>
> This fixes a bug regarding scheduling in atomic as the callback function
> may be invoked in interrupt context.
>
> Fixes: 2d97591ef43d0 ("crypto: af_alg - consolidation of duplicate code")
> Reported-by: Romain Izard 
> Signed-off-by: Stephan Mueller 

Tested-by: Romain Izard 

The issue observed with atmel-aes is not reproduced anymore.

> ---
>  crypto/af_alg.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index 337cf382718e..a41f08642eee 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -1063,8 +1063,6 @@ void af_alg_async_cb(struct crypto_async_request *_req, 
> int err)
> struct kiocb *iocb = areq->iocb;
> unsigned int resultlen;
>
> -   lock_sock(sk);
> -
> /* Buffer size written by crypto operation. */
> resultlen = areq->outlen;
>
> @@ -1073,8 +1071,6 @@ void af_alg_async_cb(struct crypto_async_request *_req, 
> int err)
> __sock_put(sk);
>
> iocb->ki_complete(iocb, err ? err : resultlen, 0);
> -
> -   release_sock(sk);
>  }
>  EXPORT_SYMBOL_GPL(af_alg_async_cb);
>
> --
> 2.13.6
>
>