* Re: CONFIG_FIPS without module loading support?
From: NTU @ 2016-09-15 17:06 UTC (permalink / raw)
To: linux-crypto
In-Reply-To: <2523179.y8adHMcoDs@tauon.atsec.com>
What did I miss from the SubmittingPatches page? Some constructive
criticism please? Step 1 is skipped due to the fact I'm using git,
patch is in proper form. Step 2, I described the patch. 3, it's one
line, so it cannot be separated. Step 4, checkpatch.pl says it's good.
The section in 5 confused me a little bit. 6, the patch is plain text.
7, it is under 300k (easily.) 8, doing it right now. 9, ok. 10, PATCH
is included in the subject. 11, it is signed, says signed off at the
bottom of the comment section. 12 I don't think is applicable to this?
13, not applicable again? 14, it is in canonical format, comment lines
do not exceed 70 characters, it has a marker line, diff output etc. 15
confused me a little. 16 it is not a series of patches.
If ANSI_CPRNG is not approved anymore for FIPS, the help section
should be updated then.
As for converting the DRBG booleans to choice, it is so that way users
cannot have both options disabled, in the case they don't read the
help for it.
Alec
On Wed, Sep 14, 2016 at 11:58 PM, Stephan Mueller <smueller@chronox.de> wrote:
> Am Mittwoch, 14. September 2016, 19:18:43 CEST schrieb NTU:
>
> Hi NTU,
>
>> Hello,
>>
>> I've never written a patch before to the official kernel mailing list
>> (that I remember) so please forgive me if I didn't send this in
>> properly. I've generated this using git format-patch HEAD~ --stdout &>
>> kconfig_fix_for_fips.patch and have attached the file in this email,
>> gathering as much as I could from the Documentation/SubmittingPatches
>> page.
>
> Please read Documentation/SubmittingPatches
>>
>> Few more things, in the help option for CRYPTO_ANSI_CPRNG, it says it
>> must be enabled if FIPS is selected, but in the dependencies for FIPS,
>> if DRBG is selected, then CRYPTO_ANSI_CPRNG doesn't need to be
>> enabled. Which one is true?
>
> The latter one. The X9.31 DRNG is not approved in FIPS mode any more.
>>
>> Secondly, in the help option for CRYPTO_DRBG_MENU, it says that one or
>> more of the DRBG types must be selected. If this is indeed true,
>> shouldn't the options within CRYPTO_DRBG_MENU be converted to
>> choice/endchoice versus just booleans? One selection for
>> CRYPTO_DRBG_HASH, another for CRYPTO_DRBG_CTR, and then a third option
>> for both? Should I submit patches for these as well,
>> feedback/thoughts?
>
> Not sure what you want to gain from it. All that the booleans do is to mark
> which types of DRBG are to be compliled. The selector whether the DRBG is
> compiled at all is CRYPTO_DRBG.
>
> Ciao
> Stephan
^ permalink raw reply
* Re: crypto-caamhash: Fine-tuning for several function implementations
From: Horia Geanta Neag @ 2016-09-15 15:30 UTC (permalink / raw)
To: SF Markus Elfring, linux-crypto@vger.kernel.org, David S. Miller,
Herbert Xu, Labbe Corentin, Russell King
Cc: LKML, kernel-janitors@vger.kernel.org, Julia Lawall
In-Reply-To: <970e9e1b-c1dc-eb28-b380-92c15e9b1961@users.sourceforge.net>
On 9/15/2016 5:37 PM, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Thu, 15 Sep 2016 16:27:23 +0200
>
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (6):
> Use kmalloc_array() in ahash_setkey()
> Rename jump labels in ahash_setkey()
> Rename a jump label in five functions
> Return a value directly in caam_hash_cra_init()
> Delete an unnecessary initialisation in seven functions
> Move common error handling code in two functions
>
> drivers/crypto/caam/caamhash.c | 111 +++++++++++++++++++----------------------
> 1 file changed, 52 insertions(+), 59 deletions(-)
>
Thanks Markus!
For patches 2-6:
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
though headline prefix should be changed to "crypto: caam -"
Horia
^ permalink raw reply
* Re: [PATCH 1/6] crypto-caamhash: Use kmalloc_array() in ahash_setkey()
From: Horia Geanta Neag @ 2016-09-15 15:12 UTC (permalink / raw)
To: SF Markus Elfring, linux-crypto@vger.kernel.org, David S. Miller,
Herbert Xu, Labbe Corentin, Russell King
Cc: LKML, kernel-janitors@vger.kernel.org, Julia Lawall
In-Reply-To: <4e1bc780-fa00-cfc9-c058-240bb899d701@users.sourceforge.net>
On 9/15/2016 5:43 PM, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Thu, 15 Sep 2016 11:20:09 +0200
>
> * A multiplication for the size determination of a memory allocation
> indicated that an array data structure should be processed.
> Thus use the corresponding function "kmalloc_array".
>
> This issue was detected by using the Coccinelle software.
>
> * Replace the specification of a data type by a pointer dereference
> to make the corresponding size determination a bit safer according to
> the Linux coding style convention.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/crypto/caam/caamhash.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
> index 9d7fc9e..f19df8f 100644
> --- a/drivers/crypto/caam/caamhash.c
> +++ b/drivers/crypto/caam/caamhash.c
> @@ -525,8 +525,9 @@ static int ahash_setkey(struct crypto_ahash *ahash,
> #endif
>
> if (keylen > blocksize) {
> - hashed_key = kmalloc(sizeof(u8) * digestsize, GFP_KERNEL |
> - GFP_DMA);
> + hashed_key = kmalloc_array(digestsize,
> + sizeof(*hashed_key),
> + GFP_KERNEL | GFP_DMA);
While correct, instead I would go with kmalloc() and get rid of sizeof(u8).
Horia
^ permalink raw reply
* [PATCH 6/6] crypto-caamhash: Move common error handling code in two functions
From: SF Markus Elfring @ 2016-09-15 14:45 UTC (permalink / raw)
To: linux-crypto, David S. Miller, Herbert Xu, Labbe Corentin,
Russell King
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <970e9e1b-c1dc-eb28-b380-92c15e9b1961@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 15 Sep 2016 16:00:55 +0200
Move statements for error handling which were identical
in two if branches to the end of these functions.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/crypto/caam/caamhash.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index adb8b19..660dc20 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -1231,9 +1231,7 @@ static int ahash_final_no_ctx(struct ahash_request *req)
state->buf_dma = dma_map_single(jrdev, buf, buflen, DMA_TO_DEVICE);
if (dma_mapping_error(jrdev, state->buf_dma)) {
dev_err(jrdev, "unable to map src\n");
- ahash_unmap(jrdev, edesc, req, digestsize);
- kfree(edesc);
- return -ENOMEM;
+ goto unmap;
}
append_seq_in_ptr(desc, state->buf_dma, buflen, 0);
@@ -1242,9 +1240,7 @@ static int ahash_final_no_ctx(struct ahash_request *req)
digestsize);
if (dma_mapping_error(jrdev, edesc->dst_dma)) {
dev_err(jrdev, "unable to map dst\n");
- ahash_unmap(jrdev, edesc, req, digestsize);
- kfree(edesc);
- return -ENOMEM;
+ goto unmap;
}
edesc->src_nents = 0;
@@ -1262,6 +1258,11 @@ static int ahash_final_no_ctx(struct ahash_request *req)
}
return ret;
+ unmap:
+ ahash_unmap(jrdev, edesc, req, digestsize);
+ kfree(edesc);
+ return -ENOMEM;
+
}
/* submit ahash update if it the first job descriptor after update */
@@ -1453,18 +1454,14 @@ static int ahash_finup_no_ctx(struct ahash_request *req)
req->nbytes);
if (ret) {
dev_err(jrdev, "unable to map S/G table\n");
- ahash_unmap(jrdev, edesc, req, digestsize);
- kfree(edesc);
- return -ENOMEM;
+ goto unmap;
}
edesc->dst_dma = map_seq_out_ptr_result(desc, jrdev, req->result,
digestsize);
if (dma_mapping_error(jrdev, edesc->dst_dma)) {
dev_err(jrdev, "unable to map dst\n");
- ahash_unmap(jrdev, edesc, req, digestsize);
- kfree(edesc);
- return -ENOMEM;
+ goto unmap;
}
#ifdef DEBUG
@@ -1481,6 +1478,11 @@ static int ahash_finup_no_ctx(struct ahash_request *req)
}
return ret;
+ unmap:
+ ahash_unmap(jrdev, edesc, req, digestsize);
+ kfree(edesc);
+ return -ENOMEM;
+
}
/* submit first update job descriptor after init */
--
2.10.0
^ permalink raw reply related
* [PATCH 5/6] crypto-caamhash: Delete an unnecessary initialisation in seven functions
From: SF Markus Elfring @ 2016-09-15 14:44 UTC (permalink / raw)
To: linux-crypto, David S. Miller, Herbert Xu, Labbe Corentin,
Russell King
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <970e9e1b-c1dc-eb28-b380-92c15e9b1961@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 15 Sep 2016 15:24:02 +0200
The local variable "ret" will be set to an appropriate value a bit later.
Thus omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/crypto/caam/caamhash.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index b1dbc53..adb8b19 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -440,7 +440,7 @@ static int hash_digest_key(struct caam_hash_ctx *ctx, const u8 *key_in,
u32 *desc;
struct split_key_result result;
dma_addr_t src_dma, dst_dma;
- int ret = 0;
+ int ret;
desc = kmalloc(CAAM_CMD_SZ * 8 + CAAM_PTR_SZ * 2, GFP_KERNEL | GFP_DMA);
if (!desc) {
@@ -517,7 +517,7 @@ static int ahash_setkey(struct crypto_ahash *ahash,
struct device *jrdev = ctx->jrdev;
int blocksize = crypto_tfm_alg_blocksize(&ahash->base);
int digestsize = crypto_ahash_digestsize(ahash);
- int ret = 0;
+ int ret;
u8 *hashed_key = NULL;
#ifdef DEBUG
@@ -975,7 +975,7 @@ static int ahash_final_ctx(struct ahash_request *req)
int sec4_sg_bytes, sec4_sg_src_index;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
- int ret = 0;
+ int ret;
sec4_sg_src_index = 1 + (buflen ? 1 : 0);
sec4_sg_bytes = sec4_sg_src_index * sizeof(struct sec4_sg_entry);
@@ -1055,7 +1055,7 @@ static int ahash_finup_ctx(struct ahash_request *req)
int src_nents, mapped_nents;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
- int ret = 0;
+ int ret;
src_nents = sg_nents_for_len(req->src, req->nbytes);
if (src_nents < 0) {
@@ -1139,7 +1139,7 @@ static int ahash_digest(struct ahash_request *req)
int digestsize = crypto_ahash_digestsize(ahash);
int src_nents, mapped_nents;
struct ahash_edesc *edesc;
- int ret = 0;
+ int ret;
src_nents = sg_nents_for_len(req->src, req->nbytes);
if (src_nents < 0) {
@@ -1218,7 +1218,7 @@ static int ahash_final_no_ctx(struct ahash_request *req)
u32 *desc;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
- int ret = 0;
+ int ret;
/* allocate space for base edesc and hw desc commands, link tables */
edesc = ahash_edesc_alloc(ctx, 0, ctx->sh_desc_digest,
@@ -1408,7 +1408,7 @@ static int ahash_finup_no_ctx(struct ahash_request *req)
int sec4_sg_bytes, sec4_sg_src_index, src_nents, mapped_nents;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
- int ret = 0;
+ int ret;
src_nents = sg_nents_for_len(req->src, req->nbytes);
if (src_nents < 0) {
--
2.10.0
^ permalink raw reply related
* [PATCH 4/6] crypto-caamhash: Return a value directly in caam_hash_cra_init()
From: SF Markus Elfring @ 2016-09-15 14:43 UTC (permalink / raw)
To: linux-crypto, David S. Miller, Herbert Xu, Labbe Corentin,
Russell King
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <970e9e1b-c1dc-eb28-b380-92c15e9b1961@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 15 Sep 2016 14:56:12 +0200
* Return a value at the end without storing it in an intermediate variable.
* Delete the local variable "ret" which became unnecessary with
this refactoring.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/crypto/caam/caamhash.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 933252f..b1dbc53 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -1846,7 +1846,6 @@ static int caam_hash_cra_init(struct crypto_tfm *tfm)
HASH_MSG_LEN + SHA256_DIGEST_SIZE,
HASH_MSG_LEN + 64,
HASH_MSG_LEN + SHA512_DIGEST_SIZE };
- int ret = 0;
/*
* Get a Job ring from Job Ring driver to ensure in-order
@@ -1866,10 +1865,7 @@ static int caam_hash_cra_init(struct crypto_tfm *tfm)
crypto_ahash_set_reqsize(__crypto_ahash_cast(tfm),
sizeof(struct caam_hash_state));
-
- ret = ahash_set_sh_desc(ahash);
-
- return ret;
+ return ahash_set_sh_desc(ahash);
}
static void caam_hash_cra_exit(struct crypto_tfm *tfm)
--
2.10.0
^ permalink raw reply related
* [PATCH 3/6] crypto-caamhash: Rename a jump label in five functions
From: SF Markus Elfring @ 2016-09-15 14:42 UTC (permalink / raw)
To: linux-crypto, David S. Miller, Herbert Xu, Labbe Corentin,
Russell King
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <970e9e1b-c1dc-eb28-b380-92c15e9b1961@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 15 Sep 2016 14:43:38 +0200
Adjust jump labels according to the current Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/crypto/caam/caamhash.c | 49 +++++++++++++++++++-----------------------
1 file changed, 22 insertions(+), 27 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 6017470..933252f 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -889,7 +889,7 @@ static int ahash_update_ctx(struct ahash_request *req)
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
edesc->sec4_sg, DMA_BIDIRECTIONAL);
if (ret)
- goto err;
+ goto unmap_ctx;
state->buf_dma = try_buf_map_to_sec4_sg(jrdev,
edesc->sec4_sg + 1,
@@ -919,7 +919,7 @@ static int ahash_update_ctx(struct ahash_request *req)
if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
dev_err(jrdev, "unable to map S/G table\n");
ret = -ENOMEM;
- goto err;
+ goto unmap_ctx;
}
append_seq_in_ptr(desc, edesc->sec4_sg_dma, ctx->ctx_len +
@@ -935,7 +935,7 @@ static int ahash_update_ctx(struct ahash_request *req)
ret = caam_jr_enqueue(jrdev, desc, ahash_done_bi, req);
if (ret)
- goto err;
+ goto unmap_ctx;
ret = -EINPROGRESS;
} else if (*next_buflen) {
@@ -953,8 +953,7 @@ static int ahash_update_ctx(struct ahash_request *req)
#endif
return ret;
-
- err:
+ unmap_ctx:
ahash_unmap_ctx(jrdev, edesc, req, ctx->ctx_len, DMA_BIDIRECTIONAL);
kfree(edesc);
return ret;
@@ -996,7 +995,7 @@ static int ahash_final_ctx(struct ahash_request *req)
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
edesc->sec4_sg, DMA_TO_DEVICE);
if (ret)
- goto err;
+ goto unmap_ctx;
state->buf_dma = try_buf_map_to_sec4_sg(jrdev, edesc->sec4_sg + 1,
buf, state->buf_dma, buflen,
@@ -1009,7 +1008,7 @@ static int ahash_final_ctx(struct ahash_request *req)
if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
dev_err(jrdev, "unable to map S/G table\n");
ret = -ENOMEM;
- goto err;
+ goto unmap_ctx;
}
append_seq_in_ptr(desc, edesc->sec4_sg_dma, ctx->ctx_len + buflen,
@@ -1020,7 +1019,7 @@ static int ahash_final_ctx(struct ahash_request *req)
if (dma_mapping_error(jrdev, edesc->dst_dma)) {
dev_err(jrdev, "unable to map dst\n");
ret = -ENOMEM;
- goto err;
+ goto unmap_ctx;
}
#ifdef DEBUG
@@ -1030,11 +1029,10 @@ static int ahash_final_ctx(struct ahash_request *req)
ret = caam_jr_enqueue(jrdev, desc, ahash_done_ctx_src, req);
if (ret)
- goto err;
+ goto unmap_ctx;
return -EINPROGRESS;
-
-err:
+ unmap_ctx:
ahash_unmap_ctx(jrdev, edesc, req, digestsize, DMA_FROM_DEVICE);
kfree(edesc);
return ret;
@@ -1094,7 +1092,7 @@ static int ahash_finup_ctx(struct ahash_request *req)
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
edesc->sec4_sg, DMA_TO_DEVICE);
if (ret)
- goto err;
+ goto unmap_ctx;
state->buf_dma = try_buf_map_to_sec4_sg(jrdev, edesc->sec4_sg + 1,
buf, state->buf_dma, buflen,
@@ -1104,14 +1102,14 @@ static int ahash_finup_ctx(struct ahash_request *req)
sec4_sg_src_index, ctx->ctx_len + buflen,
req->nbytes);
if (ret)
- goto err;
+ goto unmap_ctx;
edesc->dst_dma = map_seq_out_ptr_result(desc, jrdev, req->result,
digestsize);
if (dma_mapping_error(jrdev, edesc->dst_dma)) {
dev_err(jrdev, "unable to map dst\n");
ret = -ENOMEM;
- goto err;
+ goto unmap_ctx;
}
#ifdef DEBUG
@@ -1121,11 +1119,10 @@ static int ahash_finup_ctx(struct ahash_request *req)
ret = caam_jr_enqueue(jrdev, desc, ahash_done_ctx_src, req);
if (ret)
- goto err;
+ goto unmap_ctx;
return -EINPROGRESS;
-
-err:
+ unmap_ctx:
ahash_unmap_ctx(jrdev, edesc, req, digestsize, DMA_FROM_DEVICE);
kfree(edesc);
return ret;
@@ -1350,14 +1347,14 @@ static int ahash_update_no_ctx(struct ahash_request *req)
if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
dev_err(jrdev, "unable to map S/G table\n");
ret = -ENOMEM;
- goto err;
+ goto unmap_ctx;
}
append_seq_in_ptr(desc, edesc->sec4_sg_dma, to_hash, LDST_SGF);
ret = map_seq_out_ptr_ctx(desc, jrdev, state, ctx->ctx_len);
if (ret)
- goto err;
+ goto unmap_ctx;
#ifdef DEBUG
print_hex_dump(KERN_ERR, "jobdesc@"__stringify(__LINE__)": ",
@@ -1367,7 +1364,7 @@ static int ahash_update_no_ctx(struct ahash_request *req)
ret = caam_jr_enqueue(jrdev, desc, ahash_done_ctx_dst, req);
if (ret)
- goto err;
+ goto unmap_ctx;
ret = -EINPROGRESS;
state->update = ahash_update_ctx;
@@ -1388,8 +1385,7 @@ static int ahash_update_no_ctx(struct ahash_request *req)
#endif
return ret;
-
-err:
+ unmap_ctx:
ahash_unmap_ctx(jrdev, edesc, req, ctx->ctx_len, DMA_TO_DEVICE);
kfree(edesc);
return ret;
@@ -1548,7 +1544,7 @@ static int ahash_update_first(struct ahash_request *req)
ret = ahash_edesc_add_src(ctx, edesc, req, mapped_nents, 0, 0,
to_hash);
if (ret)
- goto err;
+ goto unmap_ctx;
if (*next_buflen)
scatterwalk_map_and_copy(next_buf, req->src, to_hash,
@@ -1558,7 +1554,7 @@ static int ahash_update_first(struct ahash_request *req)
ret = map_seq_out_ptr_ctx(desc, jrdev, state, ctx->ctx_len);
if (ret)
- goto err;
+ goto unmap_ctx;
#ifdef DEBUG
print_hex_dump(KERN_ERR, "jobdesc@"__stringify(__LINE__)": ",
@@ -1568,7 +1564,7 @@ static int ahash_update_first(struct ahash_request *req)
ret = caam_jr_enqueue(jrdev, desc, ahash_done_ctx_dst, req);
if (ret)
- goto err;
+ goto unmap_ctx;
ret = -EINPROGRESS;
state->update = ahash_update_ctx;
@@ -1588,8 +1584,7 @@ static int ahash_update_first(struct ahash_request *req)
#endif
return ret;
-
-err:
+ unmap_ctx:
ahash_unmap_ctx(jrdev, edesc, req, ctx->ctx_len, DMA_TO_DEVICE);
kfree(edesc);
return ret;
--
2.10.0
^ permalink raw reply related
* [PATCH 2/6] crypto-caamhash: Rename jump labels in ahash_setkey()
From: SF Markus Elfring @ 2016-09-15 14:41 UTC (permalink / raw)
To: linux-crypto, David S. Miller, Herbert Xu, Labbe Corentin,
Russell King
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <970e9e1b-c1dc-eb28-b380-92c15e9b1961@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 15 Sep 2016 13:54:49 +0200
Adjust jump labels according to the current Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/crypto/caam/caamhash.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index f19df8f..6017470 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -533,7 +533,7 @@ static int ahash_setkey(struct crypto_ahash *ahash,
ret = hash_digest_key(ctx, key, &keylen, hashed_key,
digestsize);
if (ret)
- goto badkey;
+ goto bad_free_key;
key = hashed_key;
}
@@ -551,14 +551,14 @@ static int ahash_setkey(struct crypto_ahash *ahash,
ret = gen_split_hash_key(ctx, key, keylen);
if (ret)
- goto badkey;
+ goto bad_free_key;
ctx->key_dma = dma_map_single(jrdev, ctx->key, ctx->split_key_pad_len,
DMA_TO_DEVICE);
if (dma_mapping_error(jrdev, ctx->key_dma)) {
dev_err(jrdev, "unable to map key i/o memory\n");
ret = -ENOMEM;
- goto map_err;
+ goto error_free_key;
}
#ifdef DEBUG
print_hex_dump(KERN_ERR, "ctx.key@"__stringify(__LINE__)": ",
@@ -571,11 +571,10 @@ static int ahash_setkey(struct crypto_ahash *ahash,
dma_unmap_single(jrdev, ctx->key_dma, ctx->split_key_pad_len,
DMA_TO_DEVICE);
}
-
-map_err:
+ error_free_key:
kfree(hashed_key);
return ret;
-badkey:
+ bad_free_key:
kfree(hashed_key);
crypto_ahash_set_flags(ahash, CRYPTO_TFM_RES_BAD_KEY_LEN);
return -EINVAL;
--
2.10.0
^ permalink raw reply related
* [PATCH 1/6] crypto-caamhash: Use kmalloc_array() in ahash_setkey()
From: SF Markus Elfring @ 2016-09-15 14:40 UTC (permalink / raw)
To: linux-crypto, David S. Miller, Herbert Xu, Labbe Corentin,
Russell King
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <970e9e1b-c1dc-eb28-b380-92c15e9b1961@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 15 Sep 2016 11:20:09 +0200
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
* Replace the specification of a data type by a pointer dereference
to make the corresponding size determination a bit safer according to
the Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/crypto/caam/caamhash.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 9d7fc9e..f19df8f 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -525,8 +525,9 @@ static int ahash_setkey(struct crypto_ahash *ahash,
#endif
if (keylen > blocksize) {
- hashed_key = kmalloc(sizeof(u8) * digestsize, GFP_KERNEL |
- GFP_DMA);
+ hashed_key = kmalloc_array(digestsize,
+ sizeof(*hashed_key),
+ GFP_KERNEL | GFP_DMA);
if (!hashed_key)
return -ENOMEM;
ret = hash_digest_key(ctx, key, &keylen, hashed_key,
--
2.10.0
^ permalink raw reply related
* crypto-caamhash: Fine-tuning for several function implementations
From: SF Markus Elfring @ 2016-09-15 14:36 UTC (permalink / raw)
To: linux-crypto, David S. Miller, Herbert Xu, Labbe Corentin,
Russell King
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <566ABCD9.1060404@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 15 Sep 2016 16:27:23 +0200
Some update suggestions were taken into account
from static source code analysis.
Markus Elfring (6):
Use kmalloc_array() in ahash_setkey()
Rename jump labels in ahash_setkey()
Rename a jump label in five functions
Return a value directly in caam_hash_cra_init()
Delete an unnecessary initialisation in seven functions
Move common error handling code in two functions
drivers/crypto/caam/caamhash.c | 111 +++++++++++++++++++----------------------
1 file changed, 52 insertions(+), 59 deletions(-)
--
2.10.0
^ permalink raw reply
* Re: [PATCHv3 06/11] crypto: omap-des: Fix support for unequal lengths
From: Tero Kristo @ 2016-09-15 9:15 UTC (permalink / raw)
To: Herbert Xu
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel, Lokesh Vutla
In-Reply-To: <20160913093506.GA30561@gondor.apana.org.au>
On 13/09/16 12:35, Herbert Xu wrote:
> On Thu, Aug 04, 2016 at 01:28:41PM +0300, Tero Kristo wrote:
>> From: Lokesh Vutla <a0131933@ti.com>
>>
>> For cases where total length of an input SGs is not same as
>> length of the input data for encryption, omap-des driver
>> crashes. This happens in the case when IPsec is trying to use
>> omap-des driver.
>>
>> To avoid this, we copy all the pages from the input SG list
>> into a contiguous buffer and prepare a single element SG list
>> for this buffer with length as the total bytes to crypt, which is
>> similar thing that is done in case of unaligned lengths.
>
> Ugh, that means copying every single packet, right?
>
> So if it's just the SG list that's the problem, why don't you
> copy that instead? That is, allocate a new SG list and set it
> up so that there is no excess data.
>
> Cheers,
>
I'll take a look at this. I have this kind of solution in place for the
re-worked SHA driver, so can probably re-use it here.
-Tero
^ permalink raw reply
* Re: [PATCHv3 00/11] crypto: omap HW crypto fixes
From: Tero Kristo @ 2016-09-15 9:12 UTC (permalink / raw)
To: Herbert Xu
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel
In-Reply-To: <20160913123849.GA31890@gondor.apana.org.au>
On 13/09/16 15:38, Herbert Xu wrote:
> On Thu, Aug 04, 2016 at 01:28:35PM +0300, Tero Kristo wrote:
>> Hi,
>>
>> This revision took quite a bit time to craft due to the rework needed
>> for sham buffer handling and export/import. I ended up implementing
>> a flush functionality for draining out the sham buffer when doing
>> export/import; just shrinking the buffer to sufficiently small size
>> impacted the performance with small data chunks too much so I dropped
>> this approach.
>>
>> The series also fixes a couple of existing issues with omap2/omap3
>> hardware acceleration, I ran a full boot test / crypto manager
>> test suite on all boards accessible to me now.
>>
>> Based on top of latest mainline, which is somewhere before 4.8-rc1
>> as of writing this, I am unable to rebase the series during the next
>> three weeks so wanted to get this out now. Targeted for 4.9 merge
>> window, some fixes could be picked up earlier though if needed.
>
> I have applied patches 1,4-5,7-11. Some of them didn't apply
> cleanly so please check the result in my tree.
>
> Thanks,
>
Thanks Herbert,
I just gave a trial for your branch, and seems to be working for me.
Also checked the patches you applied and they seem fine also.
I have also a new version of the sha buffer handling and export/import
available now, but need to cleanup it quite a bit, and figure out how to
split the patch properly.
drivers/crypto/omap-sham.c | 532
++++++++++++++++++++++++++-------------------
... It now uses sg for xmitting data where possible, and avoids the need
for a large internal buffer. The buffer size is also now properly
configurable, which can be used to overcome the performance issues if
needed (this however, requires the max statesize hack within the
crypto/ahash.c file, but thats fine.) I'll hopefully post this out maybe
tomorrow, but its going to be targeted for 4.10 I believe due to the
(ahem, rather) intrusive changes.
-Tero
^ permalink raw reply
* Re: [RFC] revamp fips_allowed flag
From: Herbert Xu @ 2016-09-15 6:26 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <2606890.Z1PDhBGeZR@tauon.atsec.com>
On Thu, Sep 15, 2016 at 08:23:05AM +0200, Stephan Mueller wrote:
>
> Where shall we draw the line here? Shall that be only for authenc, or seqiv?
> Or shall we also consider rfc4106 too, knowing that there are implementations
> which provide a full rfc4106 GCM combo (x86 for example). What about the
> current pkcspad1 template where we could expect that there may be entire HW
> implementations with that?
That's something that only you can tell us :)
For such templates we could move that info into the generic
template implementation code and have them declare themselves
as such that for any X if X is FIPS allowed then so is T(X).
This info can then be used in testmgr.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] revamp fips_allowed flag
From: Stephan Mueller @ 2016-09-15 6:23 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20160915055808.GA14688@gondor.apana.org.au>
Am Donnerstag, 15. September 2016, 13:58:08 CEST schrieb Herbert Xu:
Hi Herbert,
> Where's the pain point here? For cases like seqiv where you want to
> say if X is FIPS-allowed then so is seqiv(X) we can certainly add
> some code to testmgr to cater for that instead of listing them
> individually.
Where shall we draw the line here? Shall that be only for authenc, or seqiv?
Or shall we also consider rfc4106 too, knowing that there are implementations
which provide a full rfc4106 GCM combo (x86 for example). What about the
current pkcspad1 template where we could expect that there may be entire HW
implementations with that?
Ciao
Stephan
^ permalink raw reply
* Re: [RFC] revamp fips_allowed flag
From: Herbert Xu @ 2016-09-15 5:58 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <1818375.56xtGUSNII@tauon.atsec.com>
On Thu, Sep 15, 2016 at 07:35:43AM +0200, Stephan Mueller wrote:
>
> Wouldn't it be more prudent to move that flag into the crypto_alg and
> crypto_template data structures so that the flag is checked during the
> crypto_register_* functions? I.e. if the flag is not set and the FIPS mode is
> enabled, the cipher is simply not registered?
The problem with that is then if you have 10 implementations of a
given algorithm you'd have to change 10 places to modify its FIPS
status.
Where's the pain point here? For cases like seqiv where you want to
say if X is FIPS-allowed then so is seqiv(X) we can certainly add
some code to testmgr to cater for that instead of listing them
individually.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [RFC] revamp fips_allowed flag
From: Stephan Mueller @ 2016-09-15 5:35 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto
Hi Herbert,
The fips_allowed flag in testmgr.c shall prevent the use of "non-approved"
ciphers in FIPS mode.
With the current code, the fips_allowed flag is bound to a name a specific
cipher is referenced with. With the advent of more complex cipher string names
that can be used (for example, consider names like
"seqiv(rfc4106(gcm_base(ctr-aes-s390,ghash-generic)))", the authenc ciphers
with the two components or even the recently added pkcspad1 algorithm), it
seems that the approach in testmgr.c reached its limits. Lately more and more
entries in the alg_test_descs array were added purely to have the fips_allowed
flag set.
Wouldn't it be more prudent to move that flag into the crypto_alg and
crypto_template data structures so that the flag is checked during the
crypto_register_* functions? I.e. if the flag is not set and the FIPS mode is
enabled, the cipher is simply not registered?
With that, suggestion, the fips_allowed flag is now decoupled from the cipher
name. Complex cipher strings would now not be falsely treated as non-approved
ciphers any more.
Ciao
Stephan
--
atsec information security GmbH, Steinstraße 70, 81667 München, Germany
P: +49 89 442 49 830 - F: +49 89 442 49 831
M: +49 172 216 55 78 - HRB: 129439 (Amtsgericht München)
US: +1 949 545 4096
GF: Salvatore la Pietra, Staffan Persson
atsec it security news blog - atsec-information-security.blogspot.com
^ permalink raw reply
* Re: CONFIG_FIPS without module loading support?
From: Stephan Mueller @ 2016-09-15 4:58 UTC (permalink / raw)
To: NTU; +Cc: linux-crypto
In-Reply-To: <CAM5Ud7OVvjh1WirzLh9YGzTqQn8qG8mNMe9+0rC7Q7E-0K7Yqg@mail.gmail.com>
Am Mittwoch, 14. September 2016, 19:18:43 CEST schrieb NTU:
Hi NTU,
> Hello,
>
> I've never written a patch before to the official kernel mailing list
> (that I remember) so please forgive me if I didn't send this in
> properly. I've generated this using git format-patch HEAD~ --stdout &>
> kconfig_fix_for_fips.patch and have attached the file in this email,
> gathering as much as I could from the Documentation/SubmittingPatches
> page.
Please read Documentation/SubmittingPatches
>
> Few more things, in the help option for CRYPTO_ANSI_CPRNG, it says it
> must be enabled if FIPS is selected, but in the dependencies for FIPS,
> if DRBG is selected, then CRYPTO_ANSI_CPRNG doesn't need to be
> enabled. Which one is true?
The latter one. The X9.31 DRNG is not approved in FIPS mode any more.
>
> Secondly, in the help option for CRYPTO_DRBG_MENU, it says that one or
> more of the DRBG types must be selected. If this is indeed true,
> shouldn't the options within CRYPTO_DRBG_MENU be converted to
> choice/endchoice versus just booleans? One selection for
> CRYPTO_DRBG_HASH, another for CRYPTO_DRBG_CTR, and then a third option
> for both? Should I submit patches for these as well,
> feedback/thoughts?
Not sure what you want to gain from it. All that the booleans do is to mark
which types of DRBG are to be compliled. The selector whether the DRBG is
compiled at all is CRYPTO_DRBG.
Ciao
Stephan
^ permalink raw reply
* [PATCH -next] crypto: ccp - use kmem_cache_zalloc instead of kmem_cache_alloc/memset
From: Wei Yongjun @ 2016-09-15 3:28 UTC (permalink / raw)
To: Tom Lendacky, Gary Hook, Herbert Xu; +Cc: Wei Yongjun, linux-crypto
From: Wei Yongjun <weiyongjun1@huawei.com>
Using kmem_cache_zalloc() instead of kmem_cache_alloc() and memset().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/crypto/ccp/ccp-dmaengine.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-dmaengine.c b/drivers/crypto/ccp/ccp-dmaengine.c
index ded26f4..2e5a05c 100644
--- a/drivers/crypto/ccp/ccp-dmaengine.c
+++ b/drivers/crypto/ccp/ccp-dmaengine.c
@@ -299,12 +299,10 @@ static struct ccp_dma_desc *ccp_alloc_dma_desc(struct ccp_dma_chan *chan,
{
struct ccp_dma_desc *desc;
- desc = kmem_cache_alloc(chan->ccp->dma_desc_cache, GFP_NOWAIT);
+ desc = kmem_cache_zalloc(chan->ccp->dma_desc_cache, GFP_NOWAIT);
if (!desc)
return NULL;
- memset(desc, 0, sizeof(*desc));
-
dma_async_tx_descriptor_init(&desc->tx_desc, &chan->dma_chan);
desc->tx_desc.flags = flags;
desc->tx_desc.tx_submit = ccp_tx_submit;
^ permalink raw reply related
* [PATCH -next] crypto: omap-aes - fix error return code in omap_aes_probe()
From: Wei Yongjun @ 2016-09-15 3:27 UTC (permalink / raw)
To: Herbert Xu, Baolin Wang; +Cc: Wei Yongjun, linux-crypto
From: Wei Yongjun <weiyongjun1@huawei.com>
Fix to return error code -ENOMEM from the crypto_engine_alloc_init()
error handling case instead of 0, as done elsewhere in this function.
Fixes: 0529900a01cb ("crypto: omap-aes - Support crypto engine framework")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/crypto/omap-aes.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 2033769..fe32dd9 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -1215,8 +1215,10 @@ static int omap_aes_probe(struct platform_device *pdev)
/* Initialize crypto engine */
dd->engine = crypto_engine_alloc_init(dev, 1);
- if (!dd->engine)
+ if (!dd->engine) {
+ err = -ENOMEM;
goto err_engine;
+ }
dd->engine->prepare_cipher_request = omap_aes_prepare_req;
dd->engine->cipher_one_request = omap_aes_crypt_req;
^ permalink raw reply related
* [PATCH -next] crypto: omap-des - fix error return code in omap_des_probe()
From: Wei Yongjun @ 2016-09-15 3:27 UTC (permalink / raw)
To: Herbert Xu, Baolin; +Cc: Wei Yongjun, linux-crypto
From: Wei Yongjun <weiyongjun1@huawei.com>
Fix to return error code -ENOMEM from the crypto_engine_alloc_init()
error handling case instead of 0, as done elsewhere in this function.
Fixes: f1b77aaca85a ("crypto: omap-des - Integrate with the crypto
engine framework")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/crypto/omap-des.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-des.c b/drivers/crypto/omap-des.c
index 2b20d96..a6f6553 100644
--- a/drivers/crypto/omap-des.c
+++ b/drivers/crypto/omap-des.c
@@ -1081,8 +1081,10 @@ static int omap_des_probe(struct platform_device *pdev)
/* Initialize des crypto engine */
dd->engine = crypto_engine_alloc_init(dev, 1);
- if (!dd->engine)
+ if (!dd->engine) {
+ err = -ENOMEM;
goto err_engine;
+ }
dd->engine->prepare_cipher_request = omap_des_prepare_req;
dd->engine->cipher_one_request = omap_des_crypt_req;
^ permalink raw reply related
* Re: CONFIG_FIPS without module loading support?
From: NTU @ 2016-09-15 0:18 UTC (permalink / raw)
To: linux-crypto
In-Reply-To: <20160902142208.GA12938@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]
Hello,
I've never written a patch before to the official kernel mailing list
(that I remember) so please forgive me if I didn't send this in
properly. I've generated this using git format-patch HEAD~ --stdout &>
kconfig_fix_for_fips.patch and have attached the file in this email,
gathering as much as I could from the Documentation/SubmittingPatches
page.
Few more things, in the help option for CRYPTO_ANSI_CPRNG, it says it
must be enabled if FIPS is selected, but in the dependencies for FIPS,
if DRBG is selected, then CRYPTO_ANSI_CPRNG doesn't need to be
enabled. Which one is true?
Secondly, in the help option for CRYPTO_DRBG_MENU, it says that one or
more of the DRBG types must be selected. If this is indeed true,
shouldn't the options within CRYPTO_DRBG_MENU be converted to
choice/endchoice versus just booleans? One selection for
CRYPTO_DRBG_HASH, another for CRYPTO_DRBG_CTR, and then a third option
for both? Should I submit patches for these as well,
feedback/thoughts?
Thank you!
Alec Ari
[-- Attachment #2: kconfig_fix_for_fips.patch --]
[-- Type: text/x-patch, Size: 1029 bytes --]
From 3f6b786edef09042ff78bc7b4d61fc5a8f8cf657 Mon Sep 17 00:00:00 2001
From: Alec Ari <neotheuser@gmail.com>
Date: Wed, 14 Sep 2016 18:52:04 -0500
Subject: [PATCH] Fix Kconfig dependencies for FIPS
Currently FIPS depends on MODULE_SIG, even if MODULES is disabled.
This change allows the enabling of FIPS without support for modules.
If module loading support is enabled, only then does
FIPS require MODULE_SIG.
Signed-off-by: Alec Ari <neotheuser@gmail.com>
---
crypto/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 84d7148..fd28805 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -24,7 +24,7 @@ comment "Crypto core or helper"
config CRYPTO_FIPS
bool "FIPS 200 compliance"
depends on (CRYPTO_ANSI_CPRNG || CRYPTO_DRBG) && !CRYPTO_MANAGER_DISABLE_TESTS
- depends on MODULE_SIG
+ depends on (MODULE_SIG || !MODULES)
help
This options enables the fips boot option which is
required if you want to system to operate in a FIPS 200
--
2.7.3
^ permalink raw reply related
* [PATCH RESEND] crypto: doc - fix documentation for bulk registration functions
From: Eric Biggers @ 2016-09-14 18:56 UTC (permalink / raw)
To: herbert; +Cc: davem, linux-crypto, linux-doc, Eric Biggers
Update the documentation for crypto_register_algs() and
crypto_unregister_algs() to match the actual behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
Documentation/DocBook/crypto-API.tmpl | 38 ++++++++++++++++++++++++-----------
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/Documentation/DocBook/crypto-API.tmpl b/Documentation/DocBook/crypto-API.tmpl
index fb2a152..088b79c 100644
--- a/Documentation/DocBook/crypto-API.tmpl
+++ b/Documentation/DocBook/crypto-API.tmpl
@@ -797,7 +797,8 @@ kernel crypto API | Caller
include/linux/crypto.h and their definition can be seen below.
The former function registers a single transformation, while
the latter works on an array of transformation descriptions.
- The latter is useful when registering transformations in bulk.
+ The latter is useful when registering transformations in bulk,
+ for example when a driver implements multiple transformations.
</para>
<programlisting>
@@ -822,18 +823,31 @@ kernel crypto API | Caller
</para>
<para>
- The bulk registration / unregistration functions require
- that struct crypto_alg is an array of count size. These
- functions simply loop over that array and register /
- unregister each individual algorithm. If an error occurs,
- the loop is terminated at the offending algorithm definition.
- That means, the algorithms prior to the offending algorithm
- are successfully registered. Note, the caller has no way of
- knowing which cipher implementations have successfully
- registered. If this is important to know, the caller should
- loop through the different implementations using the single
- instance *_alg functions for each individual implementation.
+ The bulk registration/unregistration functions
+ register/unregister each transformation in the given array of
+ length count. They handle errors as follows:
</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ crypto_register_algs() succeeds if and only if it
+ successfully registers all the given transformations. If an
+ error occurs partway through, then it rolls back successful
+ registrations before returning the error code. Note that if
+ a driver needs to handle registration errors for individual
+ transformations, then it will need to use the non-bulk
+ function crypto_register_alg() instead.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ crypto_unregister_algs() tries to unregister all the given
+ transformations, continuing on error. It logs errors and
+ always returns zero.
+ </para>
+ </listitem>
+ </itemizedlist>
+
</sect1>
<sect1><title>Single-Block Symmetric Ciphers [CIPHER]</title>
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: [PATCH] crypto: squash lines for simple wrapper functions
From: Joe Perches @ 2016-09-14 2:29 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-crypto, Herbert Xu, Linux Kernel Mailing List,
David S. Miller
In-Reply-To: <CAK7LNAQs2KverOhd2rcG96=fZzsE3M5yfkZJ2ojdTU0Xvunb-Q@mail.gmail.com>
On Wed, 2016-09-14 at 11:10 +0900, Masahiro Yamada wrote:
> 2016-09-13 4:44 GMT+09:00 Joe Perches <joe@perches.com>:
> > On Tue, 2016-09-13 at 04:27 +0900, Masahiro Yamada wrote:
> > > Remove unneeded variables and assignments.
> > Was this found by visual inspection or some tool?
> > If it's via a tool, it's good to mention that in the changelog.
> I used Coccinelle, but I did not mention it
> in case somebody may say "then, please provide your semantic patch".
> As a Coccinelle beginner, I do not want to expose my stupid semantic patch.
If you get it "exposed", you'd likely learn something from others
that would give a few suggestions/tips on how to improve it.
^ permalink raw reply
* Re: [PATCH] crypto: squash lines for simple wrapper functions
From: Masahiro Yamada @ 2016-09-14 2:10 UTC (permalink / raw)
To: Joe Perches
Cc: linux-crypto, Herbert Xu, Linux Kernel Mailing List,
David S. Miller
In-Reply-To: <1473709457.11006.31.camel@perches.com>
Hi Joe,
2016-09-13 4:44 GMT+09:00 Joe Perches <joe@perches.com>:
> On Tue, 2016-09-13 at 04:27 +0900, Masahiro Yamada wrote:
>> Remove unneeded variables and assignments.
>
> Was this found by visual inspection or some tool?
>
> If it's via a tool, it's good to mention that in the changelog.
I used Coccinelle, but I did not mention it
in case somebody may say "then, please provide your semantic patch".
As a Coccinelle beginner, I do not want to expose my stupid semantic patch.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH] hwrng: pasemi-rng - Use linux/io.h instead of asm/io.h
From: Michael Ellerman @ 2016-09-14 1:54 UTC (permalink / raw)
To: Herbert Xu, PrasannaKumar Muralidharan
Cc: olof, linuxppc-dev, linux-crypto, mpm
In-Reply-To: <20160913123919.GA31835@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Tue, Sep 06, 2016 at 01:58:39PM +0530, PrasannaKumar Muralidharan wrote:
>> Checkpatch.pl warns about usage of asm/io.h. Use linux/io.h instead.
>>
>> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
>
> Patch applied. Thanks.
Oops I merged it too, my bad.
Hopefully git will work out the resolution.
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox