random(4) changes

2016-04-22 Thread Sandy Harris 
Stephan has recently proposed some extensive changes to this driver,
and I proposed a quite different set earlier. My set can be found at:
https://github.com/sandy-harris

This post tries to find the bits of both proposals that seem clearly
worth doing and entail neither large implementation problems nor large
risk of throwing out any babies with the bathwater.

Unfortunately, nothing here deals with the elephant in the room -- the
distinctly hard problem of making sure the driver is initialised well
enough & early enough. That needs a separate post, probably a separate
thread. I do not find Stepan's solution to this problem plausible and
my stuff does not claim to deal with it, though it includes some
things that might help.

I really like Stephan's idea of simplifying the interrupt handling,
replacing the multiple entropy-gathering calls in the current driver
with one routine called for all interrupts. See section 1.2 of his
doc. That seems to me a much cleaner design, easier both to analyse
and to optimise as a fast interrupt handler. I also find Stephan's
arguments that this will work better on modern  systems -- VMs,
machines with SSDs, etc. -- quite plausible.

Note, though, that I am only talking about the actual interrupt
handling, not the rest of Stephan's input handling code: the parity
calculation and XORing the resulting single bit into the entropy pool.
I'd be happier, at least initially, with a patch that only implemented
a single-source interrupt handler that gave 32 or 64 bits to existing
input-handling code.

Stephan: would you want to provide such a patch?
Ted: would you be inclined to accept it?

I also quite like Stephan's idea of replacing the two output pools
with a NIST-approved DBRG, mainly because this would probably make
getting various certifications easier. I also like the idea of using
crypto lib code for that since it makes both testing & maintenance
easier. This strikes me, though, as a do-when-convenient sort of
cleanup task, not at all urgent unless there are specific
certifications we need soon.

As for my proposals, I of course think they are full of good ideas,
but there's only one I think is really important.

In the current driver -- and I think in Stephan's, though I have not
looked at his code in any detail, only his paper -- heavy use of
/dev/urandom or the kernel get_random_bytes() call can deplete the
entropy available to /dev/random. That can be a serious problem in
some circumstances, but I think I have a fix.

You have an input pool (I) plus a blocking pool (B) & a non-blocking
pool (NB). The problem is what to do when NB must produce a lot of
output but you do not want to deplete I too much. B & NB might be
replaced by DBRGs and the problem would not change.

B must be reseeded before very /dev/random output, NB after some
number of output blocks. I used #define SAFE_OUT 503 but some other
number might be better depending how NB is implemented & how
paranoid/conservative one feels.

B can only produce one full-entropy output, suitable for /dev/random,
per reseed but B and NB are basically the same design so B can also
produce SAFE_OUT reasonably good random numbers per reseed. Use those
to reseed NB.and you reduce the load on I for reseeding NB from
SAFE_OUT (use I every time NB is reseeded) to SAFE_OUT*SAFE_OUT (use I
only to reseed B).

This does need analysis by cryptographers, but at a minimum it is
basically plausible and, even with some fairly small value for
SAFE_OUT, it greatly alleviates the problem.
--
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

HELLO DEAR

2016-04-22 Thread Melissa Robert 


Hello Dear,
how are you doing hope fine, I am (Melissa Robert) by name. i will like
to
know more about you believing that friendship is a free gift of nature.
Please get back to me as soon as possible through this my private Email.
(mr4785...@gmail.com)
thank you.

--
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: AEAD in TALITOS SEC1 versus TALITOS SEC2

2016-04-22 Thread Kim Phillips 
On Thu, 21 Apr 2016 13:31:47 +
Horia Ioan Geanta Neag  wrote:

> On 4/20/2016 3:04 PM, Christophe Leroy wrote:
> > What's the best way to implement the selection of the proper descriptor
> > type ?
> > * We can duplicate the templates but it means that when both types are
> > supported the driver with try to register each AEAD alg twice
> > * We can "on the fly" change the DESC_HDR_TYPE_IPSEC_ESP type into
> > DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU type ?
> > * We can alter the templates at startup when we know we are on a SEC1,
> > changing all templates based on DESC_HDR_TYPE_IPSEC_ESP into templates
> > based on DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU
> >
> > What would be the best approach from your point of view ?
> >
> I would go with altering the relevant entries in the template array, of
> course before the hw_supports() check.

was wondering whether assigning a different cra_priority were another
option?

Kim
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

--
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: AEAD in TALITOS SEC1 versus TALITOS SEC2

2016-04-22 Thread Kim Phillips 
On Thu, 21 Apr 2016 13:31:47 +
Horia Ioan Geanta Neag  wrote:

> On 4/20/2016 3:04 PM, Christophe Leroy wrote:
> > Today, in Talitos driver crypto alg registration is based on predefined
> > templates with a predefined descriptor type and verification against the
> > descriptors supported by the HW. This works well for ALG that require a
> > unique descriptor. But for IPsec this is slightly different:
> > * IPsec can be performed with both DESC_HDR_TYPE_IPSEC_ESP and
> > DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU
> > * DESC_HDR_TYPE_IPSEC_ESP is supported only by SEC2
> > * DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU is supported by both SEC1 and SEC2
> > * DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU is less performant than
> > DESC_HDR_TYPE_IPSEC_ESP
> > So it is natural to use DESC_HDR_TYPE_IPSEC_ESP when it is supported and
> > use DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU otherwise ?
> >
> > What's the best way to implement the selection of the proper descriptor
> > type ?
> > * We can duplicate the templates but it means that when both types are
> > supported the driver with try to register each AEAD alg twice
> > * We can "on the fly" change the DESC_HDR_TYPE_IPSEC_ESP type into
> > DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU type ?
> > * We can alter the templates at startup when we know we are on a SEC1,
> > changing all templates based on DESC_HDR_TYPE_IPSEC_ESP into templates
> > based on DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU
> >
> > What would be the best approach from your point of view ?
> >
> I would go with altering the relevant entries in the template array, of
> course before the hw_supports() check.
>
> IIUC, the "on the fly" option won't work. There has to be a valid
> descriptor type for each template entry before hw_supports().
>
> Regards,
> Horia
> --
> 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
>
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

--
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: [RFC][PATCH 0/6] /dev/random - a new approach

2016-04-22 Thread Sandy Harris 
On Thu, Apr 21, 2016 at 10:51 PM, Theodore Ts'o  wrote:

> I still have a massive problem with the claims that the "Jitter" RNG
> provides any amount of entropy.  Just because you and I might not be
> able to analyze it doesn't mean that somebody else couldn't.  After
> all, DUAL-EC DRNG was very complicated and hard to analyze.  So would
> be something like
>
>AES(NSA_KEY, COUNTER++)
>
> Very hard to analyze indeed.  Shall we run statistical tests?  They'll
> pass with flying colors.
>
> Secure?  Not so much.
>
> - Ted

Jitter, havege and my maxwell(8) all claim to get entropy from
variations in timing of simple calculations, and the docs for
all three give arguments that there really is some entropy
there.

Some of those arguments are quite strong. Mine are in
the PDF at:
https://github.com/sandy-harris/maxwell

I find any of those plausible as an external RNG feeding
random(4), though a hardware RNG or Turbid is preferable.
--
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: s5p-sss - Fix missed interrupts when working with 8 kB blocks

2016-04-22 Thread Krzysztof Kozlowski 
The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on
testing 8 kB size blocks:

$ sudo modprobe tcrypt sec=1 mode=500
testing speed of async ecb(aes) (ecb-aes-s5p) encryption
test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds 
(351536 bytes)
test 1 (128 bit key, 64 byte blocks): 21731 operations in 1 seconds 
(1390784 bytes)
test 2 (128 bit key, 256 byte blocks): 21932 operations in 1 seconds 
(5614592 bytes)
test 3 (128 bit key, 1024 byte blocks): 21685 operations in 1 seconds 
(22205440 bytes)
test 4 (128 bit key, 8192 byte blocks):

This was caused by a race issue of missed BRDMA_DONE ("Block cipher
Receiving DMA") interrupt. Device starts processing the data in DMA mode
immediately after setting length of DMA block: receiving (FCBRDMAL) or
transmitting (FCBTDMAL). The driver sets these lengths from interrupt
handler through s5p_set_dma_indata() function (or xxx_setdata()).

However the interrupt handler was first dealing with receive buffer
(dma-unmap old, dma-map new, set receive block length which starts the
operation), then with transmit buffer and finally was clearing pending
interrupts (FCINTPEND). Because of the time window between setting
receive buffer length and clearing pending interrupts, the operation on
receive buffer could end already and driver would miss new interrupt.

User manual for Exynos5422 confirms in example code that setting DMA
block lengths should be the last operation.

The tcrypt hang could be also observed in following blocked-task dmesg:

INFO: task modprobe:258 blocked for more than 120 seconds.
  Not tainted 4.6.0-rc4-next-20160419-5-g9eac8b7b7753-dirty #42
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
modprobeD c06b09d8 0   258256 0x
[] (__schedule) from [] (schedule+0x40/0xac)
[] (schedule) from [] (schedule_timeout+0x124/0x178)
[] (schedule_timeout) from [] (wait_for_common+0xb8/0x144)
[] (wait_for_common) from [] 
(test_acipher_speed+0x49c/0x740 [tcrypt])
[] (test_acipher_speed [tcrypt]) from [] 
(do_test+0x2240/0x30ec [tcrypt])
[] (do_test [tcrypt]) from [] (tcrypt_mod_init+0x48/0xa4 
[tcrypt])
[] (tcrypt_mod_init [tcrypt]) from [] 
(do_one_initcall+0x3c/0x16c)
[] (do_one_initcall) from [] (do_init_module+0x5c/0x1ac)
[] (do_init_module) from [] (load_module+0x1a30/0x1d08)
[] (load_module) from [] (SyS_finit_module+0x8c/0x98)
[] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x3c)

Fixes: a49e490c7a8a ("crypto: s5p-sss - add S5PV210 advanced crypto engine 
support")
Cc: 
Signed-off-by: Krzysztof Kozlowski 

---

Issue was easily reproduced on newer (faster?) SoCs, like Odroid XU3/XU4
(Exynos5422). Still it was kind of time-related (adding printks or
kernel debug options sometimes "was fixing" the issue). On older like
Odroid U3 with Exynos4412 this works fine...

I am marking this cc-stable because invalid operation comes from the
first version of the driver.
---
 drivers/crypto/s5p-sss.c | 53 +++-
 1 file changed, 39 insertions(+), 14 deletions(-)

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index b96532078d0c..ac6d62b3be07 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -367,43 +367,55 @@ exit:
return err;
 }
 
-static void s5p_aes_tx(struct s5p_aes_dev *dev)
+/*
+ * Returns true if new transmitting (output) data is ready and its
+ * address+length have to be written to device (by calling
+ * s5p_set_dma_outdata()). False otherwise.
+ */
+static bool s5p_aes_tx(struct s5p_aes_dev *dev)
 {
int err = 0;
+   bool ret = false;
 
s5p_unset_outdata(dev);
 
if (!sg_is_last(dev->sg_dst)) {
err = s5p_set_outdata(dev, sg_next(dev->sg_dst));
-   if (err) {
+   if (err)
s5p_aes_complete(dev, err);
-   return;
-   }
-
-   s5p_set_dma_outdata(dev, dev->sg_dst);
+   else
+   ret = true;
} else {
s5p_aes_complete(dev, err);
 
dev->busy = true;
tasklet_schedule(>tasklet);
}
+
+   return ret;
 }
 
-static void s5p_aes_rx(struct s5p_aes_dev *dev)
+/*
+ * Returns true if new receiving (input) data is ready and its
+ * address+length have to be written to device (by calling
+ * s5p_set_dma_indata()). False otherwise.
+ */
+static bool s5p_aes_rx(struct s5p_aes_dev *dev)
 {
int err;
+   bool ret = false;
 
s5p_unset_indata(dev);
 
if (!sg_is_last(dev->sg_src)) {
err = s5p_set_indata(dev, sg_next(dev->sg_src));
-   if (err) {
+   if (err)
s5p_aes_complete(dev, err);
-   return;
-   }
-
-   s5p_set_dma_indata(dev,

[PATCH 1/2] crypto: s5p-sss - Use common BIT macro

2016-04-22 Thread Krzysztof Kozlowski 
The BIT() macro is obvious and well known, so prefer to use it instead
of crafted own macro.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/crypto/s5p-sss.c | 95 
 1 file changed, 47 insertions(+), 48 deletions(-)

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 71ca6a5d636d..b96532078d0c 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -31,45 +31,44 @@
 #include 
 
 #define _SBF(s, v)  ((v) << (s))
-#define _BIT(b) _SBF(b, 1)
 
 /* Feed control registers */
 #define SSS_REG_FCINTSTAT   0x
-#define SSS_FCINTSTAT_BRDMAINT  _BIT(3)
-#define SSS_FCINTSTAT_BTDMAINT  _BIT(2)
-#define SSS_FCINTSTAT_HRDMAINT  _BIT(1)
-#define SSS_FCINTSTAT_PKDMAINT  _BIT(0)
+#define SSS_FCINTSTAT_BRDMAINT  BIT(3)
+#define SSS_FCINTSTAT_BTDMAINT  BIT(2)
+#define SSS_FCINTSTAT_HRDMAINT  BIT(1)
+#define SSS_FCINTSTAT_PKDMAINT  BIT(0)
 
 #define SSS_REG_FCINTENSET  0x0004
-#define SSS_FCINTENSET_BRDMAINTENSET_BIT(3)
-#define SSS_FCINTENSET_BTDMAINTENSET_BIT(2)
-#define SSS_FCINTENSET_HRDMAINTENSET_BIT(1)
-#define SSS_FCINTENSET_PKDMAINTENSET_BIT(0)
+#define SSS_FCINTENSET_BRDMAINTENSETBIT(3)
+#define SSS_FCINTENSET_BTDMAINTENSETBIT(2)
+#define SSS_FCINTENSET_HRDMAINTENSETBIT(1)
+#define SSS_FCINTENSET_PKDMAINTENSETBIT(0)
 
 #define SSS_REG_FCINTENCLR  0x0008
-#define SSS_FCINTENCLR_BRDMAINTENCLR_BIT(3)
-#define SSS_FCINTENCLR_BTDMAINTENCLR_BIT(2)
-#define SSS_FCINTENCLR_HRDMAINTENCLR_BIT(1)
-#define SSS_FCINTENCLR_PKDMAINTENCLR_BIT(0)
+#define SSS_FCINTENCLR_BRDMAINTENCLRBIT(3)
+#define SSS_FCINTENCLR_BTDMAINTENCLRBIT(2)
+#define SSS_FCINTENCLR_HRDMAINTENCLRBIT(1)
+#define SSS_FCINTENCLR_PKDMAINTENCLRBIT(0)
 
 #define SSS_REG_FCINTPEND   0x000C
-#define SSS_FCINTPEND_BRDMAINTP _BIT(3)
-#define SSS_FCINTPEND_BTDMAINTP _BIT(2)
-#define SSS_FCINTPEND_HRDMAINTP _BIT(1)
-#define SSS_FCINTPEND_PKDMAINTP _BIT(0)
+#define SSS_FCINTPEND_BRDMAINTP BIT(3)
+#define SSS_FCINTPEND_BTDMAINTP BIT(2)
+#define SSS_FCINTPEND_HRDMAINTP BIT(1)
+#define SSS_FCINTPEND_PKDMAINTP BIT(0)
 
 #define SSS_REG_FCFIFOSTAT  0x0010
-#define SSS_FCFIFOSTAT_BRFIFOFUL_BIT(7)
-#define SSS_FCFIFOSTAT_BRFIFOEMP_BIT(6)
-#define SSS_FCFIFOSTAT_BTFIFOFUL_BIT(5)
-#define SSS_FCFIFOSTAT_BTFIFOEMP_BIT(4)
-#define SSS_FCFIFOSTAT_HRFIFOFUL_BIT(3)
-#define SSS_FCFIFOSTAT_HRFIFOEMP_BIT(2)
-#define SSS_FCFIFOSTAT_PKFIFOFUL_BIT(1)
-#define SSS_FCFIFOSTAT_PKFIFOEMP_BIT(0)
+#define SSS_FCFIFOSTAT_BRFIFOFULBIT(7)
+#define SSS_FCFIFOSTAT_BRFIFOEMPBIT(6)
+#define SSS_FCFIFOSTAT_BTFIFOFULBIT(5)
+#define SSS_FCFIFOSTAT_BTFIFOEMPBIT(4)
+#define SSS_FCFIFOSTAT_HRFIFOFULBIT(3)
+#define SSS_FCFIFOSTAT_HRFIFOEMPBIT(2)
+#define SSS_FCFIFOSTAT_PKFIFOFULBIT(1)
+#define SSS_FCFIFOSTAT_PKFIFOEMPBIT(0)
 
 #define SSS_REG_FCFIFOCTRL  0x0014
-#define SSS_FCFIFOCTRL_DESSEL   _BIT(2)
+#define SSS_FCFIFOCTRL_DESSEL   BIT(2)
 #define SSS_HASHIN_INDEPENDENT  _SBF(0, 0x00)
 #define SSS_HASHIN_CIPHER_INPUT _SBF(0, 0x01)
 #define SSS_HASHIN_CIPHER_OUTPUT_SBF(0, 0x02)
@@ -77,52 +76,52 @@
 #define SSS_REG_FCBRDMAS0x0020
 #define SSS_REG_FCBRDMAL0x0024
 #define SSS_REG_FCBRDMAC0x0028
-#define SSS_FCBRDMAC_BYTESWAP   _BIT(1)
-#define SSS_FCBRDMAC_FLUSH  _BIT(0)
+#define SSS_FCBRDMAC_BYTESWAP   BIT(1)
+#define SSS_FCBRDMAC_FLUSH  BIT(0)
 
 #define SSS_REG_FCBTDMAS0x0030
 #define SSS_REG_FCBTDMAL0x0034
 #define SSS_REG_FCBTDMAC0x0038
-#define SSS_FCBTDMAC_BYTESWAP   _BIT(1)
-#define SSS_FCBTDMAC_FLUSH  _BIT(0)
+#define SSS_FCBTDMAC_BYTESWAP   BIT(1)
+#define SSS_FCBTDMAC_FLUSH  BIT(0)
 
 #define SSS_REG_FCHRDMAS0x0040
 #define SSS_REG_FCHRDMAL0x0044
 #define SSS_REG_FCHRDMAC0x0048
-#define SSS_FCHRDMAC_BYTESWAP   _BIT(1)
-#define SSS_FCHRDMAC_FLUSH  _BIT(0)
+#define SSS_FCHRDMAC_BYTESWAP   BIT(1)
+#define SSS_FCHRDMAC_FLUSH  BIT(0)
 
 #define SSS_REG_FCPKDMAS0x0050
 #define SSS_REG_FCPKDMAL0x0054
 #define SSS_REG_FCPKDMAC0x0058
-#define SSS_FCPKDMAC_BYTESWAP   _BIT(3)
-#define SSS_FCPKDMAC_DESCEND_BIT(2)
-#define SSS_FCPKDMAC_TRANSMIT   _BIT(1)
-#define SSS_FCPKDMAC_FLUSH  _BIT(0)
+#define SSS_FCPKDMAC_BYTESWAP   BIT(3)
+#define SSS_FCPKDMAC_DESCENDBIT(2)

[patch 2/2] crypto: mxc-scc - fix unwinding in mxc_scc_crypto_register()

2016-04-22 Thread Dan Carpenter 
There are two issues here:

1) We need to decrement "i" otherwise we unregister something that was
   not successfully registered.
2) The original code did not unregister the first element in the array
   where i is zero.

Fixes: d293b640ebd5 ('crypto: mxc-scc - add basic driver for the MXC SCC')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/crypto/mxc-scc.c b/drivers/crypto/mxc-scc.c
index 9b348a7..ff383ef 100644
--- a/drivers/crypto/mxc-scc.c
+++ b/drivers/crypto/mxc-scc.c
@@ -616,7 +616,7 @@ static struct mxc_scc_crypto_tmpl *scc_crypto_algs[] = {
 
 static int mxc_scc_crypto_register(struct mxc_scc *scc)
 {
-   unsigned int i;
+   int i;
int err = 0;
 
for (i = 0; i < ARRAY_SIZE(scc_crypto_algs); i++) {
@@ -629,7 +629,7 @@ static int mxc_scc_crypto_register(struct mxc_scc *scc)
return 0;
 
 err_out:
-   for (; i > 0; i--)
+   while (--i >= 0)
crypto_unregister_alg(_crypto_algs[i]->alg);
 
return err;
--
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 1/2] crypto: mxc-scc - signedness bugs in mxc_scc_ablkcipher_req_init()

2016-04-22 Thread Dan Carpenter 
->src_nents and ->dst_nents are unsigned so they can't be less than
zero.  I fixed this by introducing a temporary "nents" variable.

Fixes: d293b640ebd5 ('crypto: mxc-scc - add basic driver for the MXC SCC')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/crypto/mxc-scc.c b/drivers/crypto/mxc-scc.c
index 38b01bf..9b348a7 100644
--- a/drivers/crypto/mxc-scc.c
+++ b/drivers/crypto/mxc-scc.c
@@ -210,18 +210,21 @@ static int mxc_scc_ablkcipher_req_init(struct 
ablkcipher_request *req,
   struct mxc_scc_ctx *ctx)
 {
struct mxc_scc *scc = ctx->scc;
+   int nents;
 
-   ctx->src_nents = sg_nents_for_len(req->src, req->nbytes);
-   if (ctx->src_nents < 0) {
+   nents = sg_nents_for_len(req->src, req->nbytes);
+   if (nents < 0) {
dev_err(scc->dev, "Invalid number of src SC");
-   return ctx->src_nents;
+   return nents;
}
+   ctx->src_nents = nents;
 
-   ctx->dst_nents = sg_nents_for_len(req->dst, req->nbytes);
-   if (ctx->dst_nents < 0) {
+   nents = sg_nents_for_len(req->dst, req->nbytes);
+   if (nents < 0) {
dev_err(scc->dev, "Invalid number of dst SC");
-   return ctx->dst_nents;
+   return nents;
}
+   ctx->dst_nents = nents;
 
ctx->size = 0;
ctx->offset = 0;
--
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