[PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

[Joe Perches]

There are ~4300 uses of pr_warn and ~250 uses of the older
pr_warning in the kernel source tree.

Make the use of pr_warn consistent across all kernel files.

This excludes all files in tools/ as there is a separate
define pr_warning for that directory tree and pr_warn is
not used in tools/.

Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.

Miscellanea:

o Coalesce formats and realign arguments

Some files not compiled - no cross-compilers

Joe Perches (35):
  alpha: Convert remaining uses of pr_warning to pr_warn
  ARM: ep93xx: Convert remaining uses of pr_warning to pr_warn
  arm64: Convert remaining uses of pr_warning to pr_warn
  arch/blackfin: Convert remaining uses of pr_warning to pr_warn
  ia64: Convert remaining use of pr_warning to pr_warn
  powerpc: Convert remaining uses of pr_warning to pr_warn
  sh: Convert remaining uses of pr_warning to pr_warn
  sparc: Convert remaining use of pr_warning to pr_warn
  x86: Convert remaining uses of pr_warning to pr_warn
  drivers/acpi: Convert remaining uses of pr_warning to pr_warn
  block/drbd: Convert remaining uses of pr_warning to pr_warn
  gdrom: Convert remaining uses of pr_warning to pr_warn
  drivers/char: Convert remaining use of pr_warning to pr_warn
  clocksource: Convert remaining use of pr_warning to pr_warn
  drivers/crypto: Convert remaining uses of pr_warning to pr_warn
  fmc: Convert remaining use of pr_warning to pr_warn
  drivers/gpu: Convert remaining uses of pr_warning to pr_warn
  drivers/ide: Convert remaining uses of pr_warning to pr_warn
  drivers/input: Convert remaining uses of pr_warning to pr_warn
  drivers/isdn: Convert remaining uses of pr_warning to pr_warn
  drivers/macintosh: Convert remaining uses of pr_warning to pr_warn
  drivers/media: Convert remaining use of pr_warning to pr_warn
  drivers/mfd: Convert remaining uses of pr_warning to pr_warn
  drivers/mtd: Convert remaining uses of pr_warning to pr_warn
  drivers/of: Convert remaining uses of pr_warning to pr_warn
  drivers/oprofile: Convert remaining uses of pr_warning to pr_warn
  drivers/platform: Convert remaining uses of pr_warning to pr_warn
  drivers/rapidio: Convert remaining use of pr_warning to pr_warn
  drivers/scsi: Convert remaining use of pr_warning to pr_warn
  drivers/sh: Convert remaining use of pr_warning to pr_warn
  drivers/tty: Convert remaining uses of pr_warning to pr_warn
  drivers/video: Convert remaining uses of pr_warning to pr_warn
  kernel/trace: Convert remaining uses of pr_warning to pr_warn
  lib: Convert remaining uses of pr_warning to pr_warn
  sound/soc: Convert remaining uses of pr_warning to pr_warn

 arch/alpha/kernel/perf_event.c |  4 +-
 arch/arm/mach-ep93xx/core.c|  4 +-
 arch/arm64/include/asm/syscall.h   |  8 ++--
 arch/arm64/kernel/hw_breakpoint.c  |  8 ++--
 arch/arm64/kernel/smp.c|  4 +-
 arch/blackfin/kernel/nmi.c |  2 +-
 arch/blackfin/kernel/ptrace.c  |  2 +-
 arch/blackfin/mach-bf533/boards/stamp.c|  2 +-
 arch/blackfin/mach-bf537/boards/cm_bf537e.c|  2 +-
 arch/blackfin/mach-bf537/boards/cm_bf537u.c|  2 +-
 arch/blackfin/mach-bf537/boards/stamp.c|  2 +-
 arch/blackfin/mach-bf537/boards/tcm_bf537.c|  2 +-
 arch/blackfin/mach-bf561/boards/cm_bf561.c |  2 +-
 arch/blackfin/mach-bf561/boards/ezkit.c|  2 +-
 arch/blackfin/mm/isram-driver.c|  4 +-
 arch/ia64/kernel/setup.c   |  6 +--
 arch/powerpc/kernel/pci-common.c   |  4 +-
 arch/powerpc/mm/init_64.c  |  5 +--
 arch/powerpc/mm/mem.c  |  3 +-
 arch/powerpc/platforms/512x/mpc512x_shared.c   |  4 +-
 arch/powerpc/platforms/85xx/socrates_fpga_pic.c|  7 ++--
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |  2 +-
 arch/powerpc/platforms/pasemi/dma_lib.c|  4 +-
 arch/powerpc/platforms/powernv/opal.c  |  8 ++--
 arch/powerpc/platforms/powernv/pci-ioda.c  | 10 ++---
 arch/powerpc/platforms/ps3/device-init.c   | 14 +++
 arch/powerpc/platforms/ps3/mm.c|  4 +-
 arch/powerpc/platforms/ps3/os-area.c   |  2 +-
 arch/powerpc/platforms/pseries/iommu.c |  8 ++--
 arch/powerpc/platforms/pseries/setup.c |  4 +-
 arch/powerpc/sysdev/fsl_pci.c  |  9 ++---
 arch/powerpc/sysdev/mpic.c | 10 ++---
 arch/powerpc/sysdev/xics/icp-native.c  | 10 ++---
 arch/powerpc/sysdev/xics/ics-opal.c|  4 +-
 arch/powerpc/sysdev/xics/ics-rtas.c|  4 +-
 arch/powerpc/sysdev/xics/xics-common.c |  8 ++--
 arch/sh/boards/mach-sdk7786/nmi.c  |  2 +-
 arch/sh/drivers/pci/fixups-sdk7786.c   |  2 +-
 arch/sh/kernel/io_trapped.c

[PATCH 15/35] drivers/crypto: Convert remaining uses of pr_warning to pr_warn

[Joe Perches]

To enable eventual removal of pr_warning

This makes pr_warn use consistent for drivers/crypto

Prior to this patch, there were 3 uses of pr_warning and
12 uses of pr_warn in drivers/crypto

Signed-off-by: Joe Perches 
---
 drivers/crypto/n2_core.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index c5aac25a5738..82ab91adfee7 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -365,8 +365,8 @@ static int n2_hash_cra_init(struct crypto_tfm *tfm)
fallback_tfm = crypto_alloc_ahash(fallback_driver_name, 0,
  CRYPTO_ALG_NEED_FALLBACK);
if (IS_ERR(fallback_tfm)) {
-   pr_warning("Fallback driver '%s' could not be loaded!\n",
-  fallback_driver_name);
+   pr_warn("Fallback driver '%s' could not be loaded!\n",
+   fallback_driver_name);
err = PTR_ERR(fallback_tfm);
goto out;
}
@@ -402,16 +402,16 @@ static int n2_hmac_cra_init(struct crypto_tfm *tfm)
fallback_tfm = crypto_alloc_ahash(fallback_driver_name, 0,
  CRYPTO_ALG_NEED_FALLBACK);
if (IS_ERR(fallback_tfm)) {
-   pr_warning("Fallback driver '%s' could not be loaded!\n",
-  fallback_driver_name);
+   pr_warn("Fallback driver '%s' could not be loaded!\n",
+   fallback_driver_name);
err = PTR_ERR(fallback_tfm);
goto out;
}
 
child_shash = crypto_alloc_shash(n2alg->child_alg, 0, 0);
if (IS_ERR(child_shash)) {
-   pr_warning("Child shash '%s' could not be loaded!\n",
-  n2alg->child_alg);
+   pr_warn("Child shash '%s' could not be loaded!\n",
+   n2alg->child_alg);
err = PTR_ERR(child_shash);
goto out_free_fallback;
}
-- 
2.10.0.rc2.1.g053435c

Re: [PATCH] crypto: Fix next IV issue for CTS template

[Ard Biesheuvel]

Hello Libo,

On 17 February 2017 at 03:47,   wrote:
> From: Libo Wang 
>
> CTS template assumes underlying CBC algorithm will carry out next IV for
> further process.But some implementations of CBC algorithm in kernel break
> this assumption, for example, some hardware crypto drivers ignore next IV
> for performance consider, inthis case, tcry cts(cbc(aes)) test case will
> fail. This patch is trying to fix it by getting next IV information ready
> before last two blocks processed.
>
> Signed-off-by: Libo Wang 
> Signed-off-by: Dennis Chen 

Which algorithms in particular break this assumption? I recently fixed
some ARM accelerated software drivers for this reason. If there are
others, we should fix those rather than try to fix it in the CTS
driver.

> ---
>  crypto/cts.c | 29 +
>  1 file changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/crypto/cts.c b/crypto/cts.c
> index a1335d6..712164b 100644
> --- a/crypto/cts.c
> +++ b/crypto/cts.c
> @@ -154,6 +154,7 @@ static int crypto_cts_encrypt(struct skcipher_request 
> *req)
> unsigned int nbytes = req->cryptlen;
> int cbc_blocks = (nbytes + bsize - 1) / bsize - 1;
> unsigned int offset;
> +   int ret = 0;
>
> skcipher_request_set_tfm(subreq, ctx->child);
>
> @@ -174,8 +175,17 @@ static int crypto_cts_encrypt(struct skcipher_request 
> *req)
> skcipher_request_set_crypt(subreq, req->src, req->dst,
>offset, req->iv);
>
> -   return crypto_skcipher_encrypt(subreq) ?:
> -  cts_cbc_encrypt(req);
> +   /* process CBC blocks */
> +   ret = crypto_skcipher_encrypt(subreq);
> +   /* process last two blocks */
> +   if (!ret) {

What happens if an async driver returns -EINPROGRESS here?

> +   /* Get IVn-1 back */
> +   scatterwalk_map_and_copy(req->iv, req->dst, (offset - bsize), 
> bsize, 0);
> +   /* Continue last two blocks */
> +   return cts_cbc_encrypt(req);
> +   }
> +
> +   return ret;
>  }
>
>  static int cts_cbc_decrypt(struct skcipher_request *req)
> @@ -248,6 +258,8 @@ static int crypto_cts_decrypt(struct skcipher_request 
> *req)
> int cbc_blocks = (nbytes + bsize - 1) / bsize - 1;
> unsigned int offset;
> u8 *space;
> +   int ret = 0;
> +   u8 iv_next[bsize];
>
> skcipher_request_set_tfm(subreq, ctx->child);
>
> @@ -277,8 +289,17 @@ static int crypto_cts_decrypt(struct skcipher_request 
> *req)
> skcipher_request_set_crypt(subreq, req->src, req->dst,
>offset, req->iv);
>
> -   return crypto_skcipher_decrypt(subreq) ?:
> -  cts_cbc_decrypt(req);
> +   /* process last two blocks */
> +   scatterwalk_map_and_copy(iv_next, req->src, (offset - bsize), bsize, 
> 0);
> +   ret = crypto_skcipher_decrypt(subreq);
> +   if (!ret) {
> +   /* Set Next IV */
> +   subreq->iv = iv_next;
> +   /* process last two blocks */
> +   return cts_cbc_decrypt(req);
> +   }
> +
> +   return ret;
>  }
>
>  static int crypto_cts_init_tfm(struct crypto_skcipher *tfm)
> --
> 1.8.3.1
>
> 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.

Please configure your email client so it doesn't spit out these.

[PATCH] crypto: Fix next IV issue for CTS template

[Libo.Wang]

From: Libo Wang 

CTS template assumes underlying CBC algorithm will carry out next IV for
further process.But some implementations of CBC algorithm in kernel break
this assumption, for example, some hardware crypto drivers ignore next IV
for performance consider, inthis case, tcry cts(cbc(aes)) test case will
fail. This patch is trying to fix it by getting next IV information ready
before last two blocks processed.

Signed-off-by: Libo Wang 
Signed-off-by: Dennis Chen 
---
 crypto/cts.c | 29 +
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/crypto/cts.c b/crypto/cts.c
index a1335d6..712164b 100644
--- a/crypto/cts.c
+++ b/crypto/cts.c
@@ -154,6 +154,7 @@ static int crypto_cts_encrypt(struct skcipher_request *req)
unsigned int nbytes = req->cryptlen;
int cbc_blocks = (nbytes + bsize - 1) / bsize - 1;
unsigned int offset;
+   int ret = 0;

skcipher_request_set_tfm(subreq, ctx->child);

@@ -174,8 +175,17 @@ static int crypto_cts_encrypt(struct skcipher_request *req)
skcipher_request_set_crypt(subreq, req->src, req->dst,
   offset, req->iv);

-   return crypto_skcipher_encrypt(subreq) ?:
-  cts_cbc_encrypt(req);
+   /* process CBC blocks */
+   ret = crypto_skcipher_encrypt(subreq);
+   /* process last two blocks */
+   if (!ret) {
+   /* Get IVn-1 back */
+   scatterwalk_map_and_copy(req->iv, req->dst, (offset - bsize), 
bsize, 0);
+   /* Continue last two blocks */
+   return cts_cbc_encrypt(req);
+   }
+
+   return ret;
 }

 static int cts_cbc_decrypt(struct skcipher_request *req)
@@ -248,6 +258,8 @@ static int crypto_cts_decrypt(struct skcipher_request *req)
int cbc_blocks = (nbytes + bsize - 1) / bsize - 1;
unsigned int offset;
u8 *space;
+   int ret = 0;
+   u8 iv_next[bsize];

skcipher_request_set_tfm(subreq, ctx->child);

@@ -277,8 +289,17 @@ static int crypto_cts_decrypt(struct skcipher_request *req)
skcipher_request_set_crypt(subreq, req->src, req->dst,
   offset, req->iv);

-   return crypto_skcipher_decrypt(subreq) ?:
-  cts_cbc_decrypt(req);
+   /* process last two blocks */
+   scatterwalk_map_and_copy(iv_next, req->src, (offset - bsize), bsize, 0);
+   ret = crypto_skcipher_decrypt(subreq);
+   if (!ret) {
+   /* Set Next IV */
+   subreq->iv = iv_next;
+   /* process last two blocks */
+   return cts_cbc_decrypt(req);
+   }
+
+   return ret;
 }

 static int crypto_cts_init_tfm(struct crypto_skcipher *tfm)
--
1.8.3.1

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.

[PATCH v4 2/2] crypto: aead AF_ALG - overhaul memory management

[Stephan Müller]

The updated memory management is described in the top part of the code.
As one benefit of the changed memory management, the AIO and synchronous
operation is now implemented in one common function. The AF_ALG
operation uses the async kernel crypto API interface for each cipher
operation. Thus, the only difference between the AIO and sync operation
types visible from user space is:

1. the callback function to be invoked when the asynchronous operation
   is completed

2. whether to wait for the completion of the kernel crypto API operation
   or not

The change includes the overhaul of the TX and RX SGL handling. The TX
SGL holding the data sent from user space to the kernel is now dynamic
similar to algif_skcipher. This dynamic nature allows a continuous
operation of a thread sending data and a second thread receiving the
data. These threads do not need to synchronize as the kernel processes
as much data from the TX SGL to fill the RX SGL.

The caller reading the data from the kernel defines the amount of data
to be processed. Considering that the interface covers AEAD
authenticating ciphers, the reader must provide the buffer in the
correct size. Thus the reader defines the encryption size.

Signed-off-by: Stephan Mueller 
---
 crypto/algif_aead.c | 705 +---
 1 file changed, 389 insertions(+), 316 deletions(-)

diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 533265f..0a00639 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -5,12 +5,26 @@
  *
  * This file provides the user-space API for AEAD ciphers.
  *
- * This file is derived from algif_skcipher.c.
- *
  * 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.
+ *
+ * The following concept of the memory management is used:
+ *
+ * The kernel maintains two SGLs, the TX SGL and the RX SGL. The TX SGL is
+ * filled by user space with the data submitted via sendpage/sendmsg. Filling
+ * up the TX SGL does not cause a crypto operation -- the data will only be
+ * tracked by the kernel. Upon receipt of one recvmsg call, the caller must
+ * provide a buffer which is tracked with the RX SGL.
+ *
+ * During the processing of the recvmsg operation, the cipher request is
+ * allocated and prepared. As part of the recvmsg operation, the processed
+ * TX buffers are extracted from the TX SGL into a separate SGL.
+ *
+ * After the completion of the crypto operation, the RX SGL and the cipher
+ * request is released. The extracted TX SGL parts are released together with
+ * the RX SGL release.
  */
 
 #include 
@@ -24,45 +38,57 @@
 #include 
 #include 
 
-struct aead_sg_list {
-   unsigned int cur;
-   struct scatterlist sg[ALG_MAX_PAGES];
+struct aead_tsgl {
+   struct list_head list;
+   unsigned int cur;   /* Last processed SG entry */
+   struct scatterlist sg[0];   /* Array of SGs forming the SGL */
 };
 
-struct aead_async_rsgl {
+struct aead_rsgl {
struct af_alg_sgl sgl;
struct list_head list;
 };
 
 struct aead_async_req {
-   struct scatterlist *tsgl;
-   struct aead_async_rsgl first_rsgl;
-   struct list_head list;
struct kiocb *iocb;
-   unsigned int tsgls;
-   char iv[];
+   struct sock *sk;
+
+   struct aead_rsgl first_rsgl;/* First RX SG */
+   struct list_head rsgl_list; /* Track RX SGs */
+
+   struct scatterlist *tsgl;   /* priv. TX SGL of buffers to process */
+   unsigned int tsgl_entries;  /* number of entries in priv. TX SGL */
+
+   unsigned int outlen;/* Filled output buf length */
+
+   unsigned int areqlen;   /* Length of this data struct */
+   struct aead_request aead_req;   /* req ctx trails this struct */
 };
 
 struct aead_ctx {
-   struct aead_sg_list tsgl;
-   struct aead_async_rsgl first_rsgl;
-   struct list_head list;
+   struct list_head tsgl_list; /* Link to TX SGL */
 
void *iv;
+   size_t aead_assoclen;
 
-   struct af_alg_completion completion;
+   struct af_alg_completion completion;/* sync work queue */
 
-   unsigned long used;
+   unsigned int inflight;  /* Outstanding AIO ops */
+   size_t used;/* TX bytes sent to kernel */
 
-   unsigned int len;
-   bool more;
-   bool merge;
-   bool enc;
+   bool more;  /* More data to be expected? */
+   bool merge; /* Merge new data into existing SG */
+   bool enc;   /* Crypto operation: enc, dec */
 
-   size_t aead_assoclen;
-   struct aead_request aead_req;
+   unsigned int len;   /* Length of allocated memory for this struct */
+   struct crypto_aead *aead_tfm;
 };
 
+static 

[PATCH v4 0/2] crypto: AF_ALG memory management fix

[Stephan Müller]

Hi Herbert,

Changes v4:
* replace ctx->processed with a maintenance of a private recvmsg
  TX SGL
* algif_skcipher: rename skcipher_sg_list into skcipher_tsgl to make
  it consistent with algif_aead to prepare for a code consolidation

Changes v3:
* in *_pull_tsgl: make sure ctx->processed cannot be less than zero
* perform fuzzing of all input parameters with bogus values

Changes v2:
* import fix from Harsh Jain  to remove SG
  from list before freeing
* fix return code used for ki_complete to match AIO behavior
  with sync behavior
* rename variable list -> tsgl_list
* update the algif_aead patch to include a dynamic TX SGL
  allocation similar to what algif_skcipher does. This allows
  concurrent continuous read/write operations to the extent
  you requested. Although I have not implemented "pairs of
  TX/RX SGLs" as I think that is even more overhead, the
  implementation conceptually defines such pairs. The recvmsg
  call defines how much from the input data is processed.
  The caller can have arbitrary number of sendmsg calls
  where the data is added to the TX SGL before an recvmsg
  asks the kernel to process a given amount (or all) of the
  TX SGL.

With the changes, you will see a lot of code duplication now
as I deliberately tried to use the same struct and variable names,
the same function names and even the same oder of functions.
If you agree to this patch, I volunteer to provide a followup
patch that will extract the code duplication into common
functions.

Please find attached memory management updates to

- simplify the code: the old AIO memory management is very
  complex and seemingly very fragile -- the update now
  eliminates all reported bugs in the skcipher and AEAD
  interfaces which allowed the kernel to be crashed by
  an unprivileged user

- streamline the code: there is one code path for AIO and sync
  operation; the code between algif_skcipher and algif_aead
  is very similar (if that patch set is accepted, I volunteer
  to reduce code duplication by moving service operations
  into af_alg.c and to further unify the TX SGL handling)

- unify the AIO and sync operation which only differ in the
  kernel crypto API callback and whether to wait for the
  crypto operation or not

- fix all reported bugs regarding the handling of multiple
  IOCBs.

The following testing was performed:

- stress testing to verify that no memleaks exist

- testing using Tadeusz Struck AIO test tool (see
  https://github.com/tstruk/afalg_async_test) -- the AEAD test
  is not applicable any more due to the changed user space
  interface; the skcipher test works once the user space
  interface change is honored in the test code

- using the libkcapi test suite, all tests including the
  originally failing ones (AIO with multiple IOCBs) work now --
  the current libkcapi code artificially limits the AEAD
  operation to one IOCB. After altering the libkcapi code
  to allow multiple IOCBs, the testing works flawless.

Stephan Mueller (2):
  crypto: skcipher AF_ALG - overhaul memory management
  crypto: aead AF_ALG - overhaul memory management

 crypto/algif_aead.c | 705 ++--
 crypto/algif_skcipher.c | 543 +
 2 files changed, 643 insertions(+), 605 deletions(-)

-- 
2.9.3

[PATCH v4 1/2] crypto: skcipher AF_ALG - overhaul memory management

[Stephan Müller]

The updated memory management is described in the top part of the code.
As one benefit of the changed memory management, the AIO and synchronous
operation is now implemented in one common function. The AF_ALG
operation uses the async kernel crypto API interface for each cipher
operation. Thus, the only difference between the AIO and sync operation
types visible from user space is:

1. the callback function to be invoked when the asynchronous operation
   is completed

2. whether to wait for the completion of the kernel crypto API operation
   or not

In addition, the code structure is adjusted to match the structure of
algif_aead for easier code assessment.

The user space interface changed slightly as follows: the old AIO
operation returned zero upon success and < 0 in case of an error to user
space. As all other AF_ALG interfaces (including the sync skcipher
interface) returned the number of processed bytes upon success and < 0
in case of an error, the new skcipher interface (regardless of AIO or
sync) returns the number of processed bytes in case of success.

Signed-off-by: Stephan Mueller 
---
 crypto/algif_skcipher.c | 543 ++--
 1 file changed, 254 insertions(+), 289 deletions(-)

diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index a9e79d8..9b15c15 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -10,6 +10,21 @@
  * Software Foundation; either version 2 of the License, or (at your option)
  * any later version.
  *
+ * The following concept of the memory management is used:
+ *
+ * The kernel maintains two SGLs, the TX SGL and the RX SGL. The TX SGL is
+ * filled by user space with the data submitted via sendpage/sendmsg. Filling
+ * up the TX SGL does not cause a crypto operation -- the data will only be
+ * tracked by the kernel. Upon receipt of one recvmsg call, the caller must
+ * provide a buffer which is tracked with the RX SGL.
+ *
+ * During the processing of the recvmsg operation, the cipher request is
+ * allocated and prepared. As part of the recvmsg operation, the processed
+ * TX buffers are extracted from the TX SGL into a separate SGL.
+ *
+ * After the completion of the crypto operation, the RX SGL and the cipher
+ * request is released. The extracted TX SGL parts are released together with
+ * the RX SGL release.
  */
 
 #include 
@@ -23,86 +38,58 @@
 #include 
 #include 
 
-struct skcipher_sg_list {
+struct skcipher_tsgl {
struct list_head list;
-
int cur;
-
struct scatterlist sg[0];
 };
 
+struct skcipher_rsgl {
+   struct af_alg_sgl sgl;
+   struct list_head list;
+};
+
+struct skcipher_async_req {
+   struct kiocb *iocb;
+   struct sock *sk;
+
+   struct skcipher_rsgl first_sgl;
+   struct list_head rsgl_list;
+
+   struct scatterlist *tsgl;
+   unsigned int tsgl_entries;
+
+   unsigned int areqlen;
+   struct skcipher_request req;
+};
+
 struct skcipher_tfm {
struct crypto_skcipher *skcipher;
bool has_key;
 };
 
 struct skcipher_ctx {
-   struct list_head tsgl;
-   struct af_alg_sgl rsgl;
+   struct list_head tsgl_list;
 
void *iv;
 
struct af_alg_completion completion;
 
-   atomic_t inflight;
+   unsigned int inflight;
size_t used;
 
-   unsigned int len;
bool more;
bool merge;
bool enc;
 
-   struct skcipher_request req;
-};
-
-struct skcipher_async_rsgl {
-   struct af_alg_sgl sgl;
-   struct list_head list;
+   unsigned int len;
 };
 
-struct skcipher_async_req {
-   struct kiocb *iocb;
-   struct skcipher_async_rsgl first_sgl;
-   struct list_head list;
-   struct scatterlist *tsg;
-   atomic_t *inflight;
-   struct skcipher_request req;
-};
+static DECLARE_WAIT_QUEUE_HEAD(skcipher_aio_finish_wait);
 
-#define MAX_SGL_ENTS ((4096 - sizeof(struct skcipher_sg_list)) / \
+#define MAX_SGL_ENTS ((4096 - sizeof(struct skcipher_tsgl)) / \
  sizeof(struct scatterlist) - 1)
 
-static void skcipher_free_async_sgls(struct skcipher_async_req *sreq)
-{
-   struct skcipher_async_rsgl *rsgl, *tmp;
-   struct scatterlist *sgl;
-   struct scatterlist *sg;
-   int i, n;
-
-   list_for_each_entry_safe(rsgl, tmp, >list, list) {
-   af_alg_free_sg(>sgl);
-   if (rsgl != >first_sgl)
-   kfree(rsgl);
-   }
-   sgl = sreq->tsg;
-   n = sg_nents(sgl);
-   for_each_sg(sgl, sg, n, i)
-   put_page(sg_page(sg));
-
-   kfree(sreq->tsg);
-}
-
-static void skcipher_async_cb(struct crypto_async_request *req, int err)
-{
-   struct skcipher_async_req *sreq = req->data;
-   struct kiocb *iocb = sreq->iocb;
-
-   atomic_dec(sreq->inflight);
-   skcipher_free_async_sgls(sreq);
-   kzfree(sreq);
-   iocb->ki_complete(iocb, err, err);
-}
-
 static inline int skcipher_sndbuf(struct 

[bug report] crypto: cavium - Add the Virtual Function driver for CPT

[Dan Carpenter]

Hello George Cherian,

This is a semi-automatic email about new static checker warnings.

The patch c694b233295b: "crypto: cavium - Add the Virtual Function
driver for CPT" from Feb 7, 2017, leads to the following Smatch
complaint:

drivers/crypto/cavium/cpt/cptvf_main.c:899 cptvf_remove()
 error: we previously assumed 'cptvf' could be null (see line 895)

drivers/crypto/cavium/cpt/cptvf_main.c
   894  
   895  if (!cptvf)
 ^
Check for NULL.

   896  dev_err(>dev, "Invalid CPT-VF device\n");
   897  
   898  /* Convey DOWN to PF */
   899  if (cptvf_send_vf_down(cptvf)) {
   ^
Oops inside function.

   900  dev_err(>dev, "PF not responding to DOWN msg");
   901  } else {

regards,
dan carpenter

Re: [PATCH v3 0/2] crypto: AF_ALG memory management fix

[Stephan Müller]

Am Donnerstag, 16. Februar 2017, 20:10:21 CET schrieb Herbert Xu:

Hi Herbert,

> On Wed, Feb 15, 2017 at 09:47:19AM +0100, Stephan Müller wrote:
> > as I just saw that you marked my patch with changes requested in
> > patchwork,
> > may I ask which changes should be applied?
> 
> I thought we agreed that we would not do the TX offset thing and
> keep the existing semantics of consuming all TX data given an RX
> request.

Ok, will do.

Ciao
Stephan

Re: [PATCH v3 0/2] crypto: AF_ALG memory management fix

[Herbert Xu]

On Wed, Feb 15, 2017 at 09:47:19AM +0100, Stephan Müller wrote:
> 
> as I just saw that you marked my patch with changes requested in patchwork, 
> may I ask which changes should be applied?

I thought we agreed that we would not do the TX offset thing and
keep the existing semantics of consuming all TX data given an RX
request.

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