linux-next: build warnings after merge of the crypto tree

linux-next: build warnings after merge of the crypto tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

Hi Herbert,

After merging the crypto tree, today's linux-next build (powerpc
ppc44x_defconfig, i386 defconfig and sparc defconfig) produced these
warnings:

In file included from crypto/testmgr.c:30:0:
include/crypto/drbg.h: In function 'drbg_max_addtl':
include/crypto/drbg.h:157:2: warning: left shift count >= width of type
  return (1UL<<35);
  ^
include/crypto/drbg.h: In function 'drbg_max_requests':
include/crypto/drbg.h:163:2: warning: left shift count >= width of type
  return (1UL<<48);
  ^

Introduced by commit 05c81ccd9087 ("crypto: drbg - remove configuration
of fixed values").  These are all 32 bit builds.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: build warnings after merge of the crypto tree

[Herbert Xu]

On Tue, Aug 26, 2014 at 04:14:56PM +1000, Stephen Rothwell wrote:
> Hi Herbert,
> 
> After merging the crypto tree, today's linux-next build (powerpc
> ppc44x_defconfig, i386 defconfig and sparc defconfig) produced these
> warnings:
> 
> In file included from crypto/testmgr.c:30:0:
> include/crypto/drbg.h: In function 'drbg_max_addtl':
> include/crypto/drbg.h:157:2: warning: left shift count >= width of type
>   return (1UL<<35);
>   ^
> include/crypto/drbg.h: In function 'drbg_max_requests':
> include/crypto/drbg.h:163:2: warning: left shift count >= width of type
>   return (1UL<<48);
>   ^
> 
> Introduced by commit 05c81ccd9087 ("crypto: drbg - remove configuration
> of fixed values").  These are all 32 bit builds.

Stephan, could you take a look at this?

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

Re: linux-next: build warnings after merge of the crypto tree

[Stephan Mueller]

Am Dienstag, 26. August 2014, 14:38:12 schrieb Herbert Xu:

Hi Herbert,

>On Tue, Aug 26, 2014 at 04:14:56PM +1000, Stephen Rothwell wrote:
>> Hi Herbert,
>> 
>> After merging the crypto tree, today's linux-next build (powerpc
>> ppc44x_defconfig, i386 defconfig and sparc defconfig) produced these
>> warnings:
>> 
>> In file included from crypto/testmgr.c:30:0:
>> include/crypto/drbg.h: In function 'drbg_max_addtl':
>> include/crypto/drbg.h:157:2: warning: left shift count >= width of
>> type> 
>>   return (1UL<<35);
>>   ^
>> 
>> include/crypto/drbg.h: In function 'drbg_max_requests':
>> include/crypto/drbg.h:163:2: warning: left shift count >= width of
>> type> 
>>   return (1UL<<48);
>>   ^
>> 
>> Introduced by commit 05c81ccd9087 ("crypto: drbg - remove
>> configuration of fixed values").  These are all 32 bit builds.
>
>Stephan, could you take a look at this?

I am on it. Thanks.
>
>Thanks,


Ciao
Stephan

[PATCH] DRBG: fix bit shifting on 32 bit systems

[Stephan Mueller]

Use ULL to mark a 64 bit value.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 include/crypto/drbg.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index 3d8e73a..dd52aee 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -154,13 +154,13 @@ static inline size_t drbg_max_request_bytes(struct drbg_state *drbg)
 static inline size_t drbg_max_addtl(struct drbg_state *drbg)
 {
 	/* SP800-90A requires 2**35 bytes additional info str / pers str */
-	return (1UL<<35);
+	return (1ULL<<35);
 }
 
 static inline size_t drbg_max_requests(struct drbg_state *drbg)
 {
 	/* SP800-90A requires 2**48 maximum requests before reseeding */
-	return (1UL<<48);
+	return (1ULL<<48);
 }
 
 /*
-- 
1.9.3

Re: [PATCH] DRBG: fix bit shifting on 32 bit systems

[Herbert Xu]

On Tue, Aug 26, 2014 at 09:31:02AM +0200, Stephan Mueller wrote:
> Use ULL to mark a 64 bit value.
> 
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>

I don't think this works as size_t is still 32-bit which means
that you'll return zero.

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

Re: [PATCH] DRBG: fix bit shifting on 32 bit systems

[Stephan Mueller]

Am Dienstag, 26. August 2014, 15:32:19 schrieb Herbert Xu:

Hi Herbert,

> On Tue, Aug 26, 2014 at 09:31:02AM +0200, Stephan Mueller wrote:
> > Use ULL to mark a 64 bit value.
> > 
> > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > Reported-by: kbuild test robot <fengguang.wu@intel.com>
> > Signed-off-by: Stephan Mueller <smueller@chronox.de>
> 
> I don't think this works as size_t is still 32-bit which means
> that you'll return zero.

Oops, yes. Thank you for catching this. I guess I need __u64 for this value. A 
patch will come shortly.
> 
> Cheers,


-- 
Ciao
Stephan

[PATCH] DRBG: fix maximum value checks on 32 bit systems

[Stephan Mueller]

The maximum values for additional input string or generated blocks is
larger than 1<<32. To ensure a sensible value on 32 bit systems, return
SIZE_MAX on 32 bit systems. This value is lower than the maximum allowed
values defined in SP800-90A. The standard allow lower maximum values,
but not larger values.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 include/crypto/drbg.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index 3d8e73a..5ac482a 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -154,13 +154,21 @@ static inline size_t drbg_max_request_bytes(struct drbg_state *drbg)
 static inline size_t drbg_max_addtl(struct drbg_state *drbg)
 {
 	/* SP800-90A requires 2**35 bytes additional info str / pers str */
+#if (__BITS_PER_LONG == 32)
+	return SIZE_MAX;
+#else
 	return (1UL<<35);
+#endif
 }
 
 static inline size_t drbg_max_requests(struct drbg_state *drbg)
 {
 	/* SP800-90A requires 2**48 maximum requests before reseeding */
+#if (__BITS_PER_LONG == 32)
+	return SIZE_MAX;
+#else
 	return (1UL<<48);
+#endif
 }
 
 /*
-- 
1.9.3

Re: [PATCH] DRBG: fix maximum value checks on 32 bit systems

[Herbert Xu]

On Tue, Aug 26, 2014 at 10:06:52AM +0200, Stephan Mueller wrote:
> The maximum values for additional input string or generated blocks is
> larger than 1<<32. To ensure a sensible value on 32 bit systems, return
> SIZE_MAX on 32 bit systems. This value is lower than the maximum allowed
> values defined in SP800-90A. The standard allow lower maximum values,
> but not larger values.
> 
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>

Unfortunately there's a place in drbg where you add one to
drbg_max_addtl which will cause it to overflow back to zero.

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

[PATCH v2] DRBG: fix maximum value checks on 32 bit systems

[Stephan Mueller]

The maximum values for additional input string or generated blocks is
larger than 1<<32. To ensure a sensible value on 32 bit systems, return
SIZE_MAX on 32 bit systems. This value is lower than the maximum
allowed values defined in SP800-90A. The standard allow lower maximum
values, but not larger values.

SIZE_MAX - 1 is used for drbg_max_addtl to allow
drbg_healthcheck_sanity to check the enforcement of the variable
without wrapping.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 include/crypto/drbg.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index 3d8e73a..5186f75 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -154,13 +154,26 @@ static inline size_t drbg_max_request_bytes(struct drbg_state *drbg)
 static inline size_t drbg_max_addtl(struct drbg_state *drbg)
 {
 	/* SP800-90A requires 2**35 bytes additional info str / pers str */
+#if (__BITS_PER_LONG == 32)
+	/*
+	 * SP800-90A allows smaller maximum numbers to be returned -- we
+	 * return SIZE_MAX - 1 to allow the verification of the enforcement
+	 * of this value in drbg_healthcheck_sanity.
+	 */
+	return (SIZE_MAX - 1);
+#else
 	return (1UL<<35);
+#endif
 }
 
 static inline size_t drbg_max_requests(struct drbg_state *drbg)
 {
 	/* SP800-90A requires 2**48 maximum requests before reseeding */
+#if (__BITS_PER_LONG == 32)
+	return SIZE_MAX;
+#else
 	return (1UL<<48);
+#endif
 }
 
 /*
-- 
1.9.3

Re: [PATCH v2] DRBG: fix maximum value checks on 32 bit systems

[Herbert Xu]

On Tue, Aug 26, 2014 at 10:29:45AM +0200, Stephan Mueller wrote:
> The maximum values for additional input string or generated blocks is
> larger than 1<<32. To ensure a sensible value on 32 bit systems, return
> SIZE_MAX on 32 bit systems. This value is lower than the maximum
> allowed values defined in SP800-90A. The standard allow lower maximum
> values, but not larger values.
> 
> SIZE_MAX - 1 is used for drbg_max_addtl to allow
> drbg_healthcheck_sanity to check the enforcement of the variable
> without wrapping.

This is really ugly but OK.  However, I'm not sure how the sanity
check ever worked.  It would appear that the drbg_generate call in
drbg_healthcheck_sanity should always fail because you explicitly
set addtl->len to drbg_max_addtl + 1, which should trigger the
"DRBG: additional information string too long" error, no?

Obviously it's working for you but I'd like to understand why
it's working and whether it'll continue to work.

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

Re: [PATCH v2] DRBG: fix maximum value checks on 32 bit systems

[Stephan Mueller]

Am Dienstag, 26. August 2014, 16:43:43 schrieb Herbert Xu:

Hi Herbert,

> On Tue, Aug 26, 2014 at 10:29:45AM +0200, Stephan Mueller wrote:
> > The maximum values for additional input string or generated blocks is
> > larger than 1<<32. To ensure a sensible value on 32 bit systems, return
> > SIZE_MAX on 32 bit systems. This value is lower than the maximum
> > allowed values defined in SP800-90A. The standard allow lower maximum
> > values, but not larger values.
> > 
> > SIZE_MAX - 1 is used for drbg_max_addtl to allow
> > drbg_healthcheck_sanity to check the enforcement of the variable
> > without wrapping.
> 
> This is really ugly but OK.  However, I'm not sure how the sanity
> check ever worked.  It would appear that the drbg_generate call in
> drbg_healthcheck_sanity should always fail because you explicitly
> set addtl->len to drbg_max_addtl + 1, which should trigger the
> "DRBG: additional information string too long" error, no?

That is exactly what the test shall do: the test is intended to check whether 
the maximum values are enforced. And it does that by checking whether an error 
is returned.

	/* get the maximum value */
        max_addtllen = drbg_max_addtl(drbg);
	/* add one to definitely overflow the maximum value */
        drbg_string_fill(&addtl, buf, max_addtllen + 1);
        /* overflow addtllen with additonal info string */
        len = drbg_generate(drbg, buf, OUTBUFLEN, &addtl);
	/*
	 * check that the drbg_generate does not return a positive
	 * value, i.e. check that drbg_generate does not generate anything
	 */
        BUG_ON(0 < len);
> 
> Obviously it's working for you but I'd like to understand why
> it's working and whether it'll continue to work.
> 
> Thanks,


-- 
Ciao
Stephan

Re: [PATCH v2] DRBG: fix maximum value checks on 32 bit systems

[Herbert Xu]

On Tue, Aug 26, 2014 at 10:52:45AM +0200, Stephan Mueller wrote:
> Am Dienstag, 26. August 2014, 16:43:43 schrieb Herbert Xu:
> 
> Hi Herbert,
> 
> > On Tue, Aug 26, 2014 at 10:29:45AM +0200, Stephan Mueller wrote:
> > > The maximum values for additional input string or generated blocks is
> > > larger than 1<<32. To ensure a sensible value on 32 bit systems, return
> > > SIZE_MAX on 32 bit systems. This value is lower than the maximum
> > > allowed values defined in SP800-90A. The standard allow lower maximum
> > > values, but not larger values.
> > > 
> > > SIZE_MAX - 1 is used for drbg_max_addtl to allow
> > > drbg_healthcheck_sanity to check the enforcement of the variable
> > > without wrapping.
> > 
> > This is really ugly but OK.  However, I'm not sure how the sanity
> > check ever worked.  It would appear that the drbg_generate call in
> > drbg_healthcheck_sanity should always fail because you explicitly
> > set addtl->len to drbg_max_addtl + 1, which should trigger the
> > "DRBG: additional information string too long" error, no?
> 
> That is exactly what the test shall do: the test is intended to check whether 
> the maximum values are enforced. And it does that by checking whether an error 
> is returned.

OK that makes sense.  Patch applied.  Thanks!
-- 
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

Re: [PATCH v2] DRBG: fix maximum value checks on 32 bit systems

[Stephan Mueller]

Am Dienstag, 26. August 2014, 16:58:53 schrieb Herbert Xu:

Hi Herbert,

> On Tue, Aug 26, 2014 at 10:52:45AM +0200, Stephan Mueller wrote:
> > Am Dienstag, 26. August 2014, 16:43:43 schrieb Herbert Xu:
> > 
> > Hi Herbert,
> > 
> > > On Tue, Aug 26, 2014 at 10:29:45AM +0200, Stephan Mueller wrote:
> > > > The maximum values for additional input string or generated blocks is
> > > > larger than 1<<32. To ensure a sensible value on 32 bit systems,
> > > > return
> > > > SIZE_MAX on 32 bit systems. This value is lower than the maximum
> > > > allowed values defined in SP800-90A. The standard allow lower maximum
> > > > values, but not larger values.
> > > > 
> > > > SIZE_MAX - 1 is used for drbg_max_addtl to allow
> > > > drbg_healthcheck_sanity to check the enforcement of the variable
> > > > without wrapping.
> > > 
> > > This is really ugly but OK.  However, I'm not sure how the sanity
> > > check ever worked.  It would appear that the drbg_generate call in
> > > drbg_healthcheck_sanity should always fail because you explicitly
> > > set addtl->len to drbg_max_addtl + 1, which should trigger the
> > > "DRBG: additional information string too long" error, no?
> > 
> > That is exactly what the test shall do: the test is intended to check
> > whether the maximum values are enforced. And it does that by checking
> > whether an error is returned.
> 
> OK that makes sense.  Patch applied.  Thanks!

I am wondering about the current code in Linus' tree though considering the 
applied patch:

Linus' code contains:

static inline size_t drbg_max_addtl(struct drbg_state *drbg)
{
        return (1UL<<(drbg->core->max_addtllen));
}

static inline size_t drbg_max_requests(struct drbg_state *drbg)
{
        return (1UL<<(drbg->core->max_req));
}

The max_addtllen and max_req are defined in drbg_cores[] in crypto/drbg.c for 
each DRBG type. As size_t on a 32 bit system is 32 bit the bit shifts would 
not work either.

Thus, I am wondering whether the just applied patch would need to go to Linus 
tree too? I would think that the following patch would be in order:

static inline size_t drbg_max_addtl(struct drbg_state *drbg)
{
#if (__BITS_PER_LONG == 32)
        return (SIZE_MAX - 1);
#else
        return (1UL<<(drbg->core->max_addtllen));
#endif
}

static inline size_t drbg_max_requests(struct drbg_state *drbg)
{
#if (__BITS_PER_LONG == 32)
        return SIZE_MAX;
#else
        return (1UL<<(drbg->core->max_req));
#endif
}


-- 
Ciao
Stephan

Re: [PATCH v2] DRBG: fix maximum value checks on 32 bit systems

[Herbert Xu]

On Tue, Aug 26, 2014 at 11:36:54AM +0200, Stephan Mueller wrote:
>
> The max_addtllen and max_req are defined in drbg_cores[] in crypto/drbg.c for 
> each DRBG type. As size_t on a 32 bit system is 32 bit the bit shifts would 
> not work either.
> 
> Thus, I am wondering whether the just applied patch would need to go to Linus 
> tree too? I would think that the following patch would be in order:

Have you actually tested this on a 32-bit box? If so and it
actually works then I'd be happy to push it.

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

Re: [PATCH v2] DRBG: fix maximum value checks on 32 bit systems

[Stephan Mueller]

Am Mittwoch, 27. August 2014, 21:35:28 schrieb Herbert Xu:

Hi Herbert,

>On Tue, Aug 26, 2014 at 11:36:54AM +0200, Stephan Mueller wrote:
>> The max_addtllen and max_req are defined in drbg_cores[] in
>> crypto/drbg.c for each DRBG type. As size_t on a 32 bit system is 32
>> bit the bit shifts would not work either.
>> 
>> Thus, I am wondering whether the just applied patch would need to go
>> to Linus
>> tree too? I would think that the following patch would be in order:
>Have you actually tested this on a 32-bit box? If so and it
>actually works then I'd be happy to push it.

I will have it tested by tomorrow.
>
>Cheers,


Ciao
Stephan

Re: [PATCH v2] DRBG: fix maximum value checks on 32 bit systems

[Stephan Mueller]

Am Mittwoch, 27. August 2014, 21:35:28 schrieb Herbert Xu:

Hi Herbert,

> On Tue, Aug 26, 2014 at 11:36:54AM +0200, Stephan Mueller wrote:
> > The max_addtllen and max_req are defined in drbg_cores[] in crypto/drbg.c
> > for each DRBG type. As size_t on a 32 bit system is 32 bit the bit shifts
> > would not work either.
> > 
> > Thus, I am wondering whether the just applied patch would need to go to
> > Linus
> > tree too? I would think that the following patch would be in order:
> Have you actually tested this on a 32-bit box? If so and it
> actually works then I'd be happy to push it.

I tested the current cryptodev-2.6:

- on x86_64 and on i386

- in FIPS mode and without FIPS mode on both arches

- executing the CAVS testing in FIPS mode and non-FIPS mode on both arches

- executing stress tests (obtain random values at a size randomly selected 
between 1 through 1 million bytes) in both modes on both arches

- adding some debug printks to check for the drbg_max_addtl() on both arches

- adding some debug printks to check for the drbg_max_requests() on both 
arches

I found a bug that was introduced with 
bc034ef5573ef4d81daa666c02a3df1ad28e24a7 when booting in FIPS mode, i.e. it is 
not in Linus' tree. The patch will be on your desk shortly.

Thus, the fix in b9347aff91ce4789619168539f08202d8d6a1177 works. However, this 
patch is based on 05c81ccd9087d238c10b234eadb55632742e5518. So, if we want to 
fix Linus' tree with minimal impact, either these two patches are pushed to 
Linus or I have to port b9347aff91ce4789619168539f08202d8d6a1177 to the 
current Linus tree.
> 
> Cheers,


-- 
Ciao
Stephan

DRBG: remove test for uninitialized DRBG handle

[Stephan Mueller]

The drbg_healthcheck() contains a test to call the DRBG with an
uninitialized DRBG cipher handle. As this is an inappropriate use of the
kernel crypto API to try to generate random numbers before
initialization, checks verifying for an initialized DRBG during the
generate function have been removed in previous patches.

Now, the drbg_healthcheck test trying to generate random numbers with
an uninstantiated DRBG must also be removed.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/drbg.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/crypto/drbg.c b/crypto/drbg.c
index 39ed918..54cfd48 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1872,9 +1872,6 @@ static inline int __init drbg_healthcheck_sanity(void)
 	/* overflow max addtllen with personalization string */
 	ret = drbg_instantiate(drbg, &addtl, coreref, pr);
 	BUG_ON(0 == ret);
-	/* test uninstantated DRBG */
-	len = drbg_generate(drbg, buf, (max_request_bytes + 1), NULL);
-	BUG_ON(0 < len);
 	/* all tests passed */
 	rc = 0;
 
-- 
1.9.3

[PATCH v2] DRBG: remove check for uninitialized DRBG handle

[Stephan Mueller]

The drbg_healthcheck() contained a test to call the DRBG with an
uninitialized DRBG cipher handle. As this is an inappropriate use of the
kernel crypto API to try to generate random numbers before
initialization, checks verifying for an initialized DRBG have been
removed in previous patches.

Now, the drbg_healthcheck test must also be removed.

Changes V2: Added patch marker to email subject line.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/drbg.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/crypto/drbg.c b/crypto/drbg.c
index 39ed918..54cfd48 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1872,9 +1872,6 @@ static inline int __init drbg_healthcheck_sanity(void)
 	/* overflow max addtllen with personalization string */
 	ret = drbg_instantiate(drbg, &addtl, coreref, pr);
 	BUG_ON(0 == ret);
-	/* test uninstantated DRBG */
-	len = drbg_generate(drbg, buf, (max_request_bytes + 1), NULL);
-	BUG_ON(0 < len);
 	/* all tests passed */
 	rc = 0;
 
-- 
1.9.3

Re: [PATCH v2] DRBG: remove check for uninitialized DRBG handle

[Stephan Mueller]

Am Montag, 1. September 2014, 07:11:20 schrieb Stephan Mueller:

Hi Herbert,

may I ask for consideration of this patch as this covers an oops FIPS mode?

In addition, may I ask for guidance on how to fix the 32 bit code path in 
Linus' tree as asked on 28.8? To quote: "Thus, the fix in 
b9347aff91ce4789619168539f08202d8d6a1177 works. However, this 
patch is based on 05c81ccd9087d238c10b234eadb55632742e5518. So, if we want to 
fix Linus' tree with minimal impact, either these two patches are pushed to 
Linus or I have to port b9347aff91ce4789619168539f08202d8d6a1177 to the 
current Linus tree."

Thanks a lot
Stephan

> The drbg_healthcheck() contained a test to call the DRBG with an
> uninitialized DRBG cipher handle. As this is an inappropriate use of the
> kernel crypto API to try to generate random numbers before
> initialization, checks verifying for an initialized DRBG have been
> removed in previous patches.
> 
> Now, the drbg_healthcheck test must also be removed.
> 
> Changes V2: Added patch marker to email subject line.
> 
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
> ---
>  crypto/drbg.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/crypto/drbg.c b/crypto/drbg.c
> index 39ed918..54cfd48 100644
> --- a/crypto/drbg.c
> +++ b/crypto/drbg.c
> @@ -1872,9 +1872,6 @@ static inline int __init drbg_healthcheck_sanity(void)
> /* overflow max addtllen with personalization string */
>  	ret = drbg_instantiate(drbg, &addtl, coreref, pr);
>  	BUG_ON(0 == ret);
> -	/* test uninstantated DRBG */
> -	len = drbg_generate(drbg, buf, (max_request_bytes + 1), NULL);
> -	BUG_ON(0 < len);
>  	/* all tests passed */
>  	rc = 0;


-- 
Ciao
Stephan

Re: [PATCH v2] DRBG: remove check for uninitialized DRBG handle

[Herbert Xu]

On Wed, Sep 03, 2014 at 03:33:16AM +0200, Stephan Mueller wrote:
> Am Montag, 1. September 2014, 07:11:20 schrieb Stephan Mueller:
> 
> Hi Herbert,
> 
> may I ask for consideration of this patch as this covers an oops FIPS mode?
> 
> In addition, may I ask for guidance on how to fix the 32 bit code path in 
> Linus' tree as asked on 28.8? To quote: "Thus, the fix in 
> b9347aff91ce4789619168539f08202d8d6a1177 works. However, this 
> patch is based on 05c81ccd9087d238c10b234eadb55632742e5518. So, if we want to 
> fix Linus' tree with minimal impact, either these two patches are pushed to 
> Linus or I have to port b9347aff91ce4789619168539f08202d8d6a1177 to the 
> current Linus tree."

I will take care of this.

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

Re: [PATCH v2] DRBG: remove check for uninitialized DRBG handle

[Stephan Mueller]

Am Donnerstag, 4. September 2014, 07:21:29 schrieb Herbert Xu:

Hi Herbert,

> On Wed, Sep 03, 2014 at 03:33:16AM +0200, Stephan Mueller wrote:
> > Am Montag, 1. September 2014, 07:11:20 schrieb Stephan Mueller:
> > 
> > Hi Herbert,
> > 
> > may I ask for consideration of this patch as this covers an oops FIPS
> > mode?
> > 
> > In addition, may I ask for guidance on how to fix the 32 bit code path in
> > Linus' tree as asked on 28.8? To quote: "Thus, the fix in
> > b9347aff91ce4789619168539f08202d8d6a1177 works. However, this
> > patch is based on 05c81ccd9087d238c10b234eadb55632742e5518. So, if we want
> > to fix Linus' tree with minimal impact, either these two patches are
> > pushed to Linus or I have to port
> > b9347aff91ce4789619168539f08202d8d6a1177 to the current Linus tree."
> 
> I will take care of this.

Thank you.
> 
> Cheers,


-- 
Ciao
Stephan

Re: [PATCH v2] DRBG: remove check for uninitialized DRBG handle

[Herbert Xu]

On Thu, Sep 04, 2014 at 01:50:32AM +0200, Stephan Mueller wrote:
> Am Donnerstag, 4. September 2014, 07:21:29 schrieb Herbert Xu:
> 
> Hi Herbert,
> 
> > On Wed, Sep 03, 2014 at 03:33:16AM +0200, Stephan Mueller wrote:
> > > Am Montag, 1. September 2014, 07:11:20 schrieb Stephan Mueller:
> > > 
> > > Hi Herbert,
> > > 
> > > may I ask for consideration of this patch as this covers an oops FIPS
> > > mode?
> > > 
> > > In addition, may I ask for guidance on how to fix the 32 bit code path in
> > > Linus' tree as asked on 28.8? To quote: "Thus, the fix in
> > > b9347aff91ce4789619168539f08202d8d6a1177 works. However, this
> > > patch is based on 05c81ccd9087d238c10b234eadb55632742e5518. So, if we want
> > > to fix Linus' tree with minimal impact, either these two patches are
> > > pushed to Linus or I have to port
> > > b9347aff91ce4789619168539f08202d8d6a1177 to the current Linus tree."
> > 
> > I will take care of this.
> 
> Thank you.

Here is the patch I will add for 3.17:

commit fb38ab4cd05e11184fd2c3ef916fa106ecc505fc
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Fri Sep 5 15:52:28 2014 +0800

    crypto: drbg - backport "fix maximum value checks on 32 bit systems"
    
    This is a backport of commit b9347aff91ce4789619168539f08202d8d6a1177.
    This backport is needed as without it the code will crash on 32-bit
    systems.
    
    The maximum values for additional input string or generated blocks is
    larger than 1<<32. To ensure a sensible value on 32 bit systems, return
    SIZE_MAX on 32 bit systems. This value is lower than the maximum
    allowed values defined in SP800-90A. The standard allow lower maximum
    values, but not larger values.
    
    SIZE_MAX - 1 is used for drbg_max_addtl to allow
    drbg_healthcheck_sanity to check the enforcement of the variable
    without wrapping.
    
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index 831d786..882675e 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -162,12 +162,25 @@ static inline size_t drbg_max_request_bytes(struct drbg_state *drbg)
 
 static inline size_t drbg_max_addtl(struct drbg_state *drbg)
 {
+#if (__BITS_PER_LONG == 32)
+	/*
+	 * SP800-90A allows smaller maximum numbers to be returned -- we
+	 * return SIZE_MAX - 1 to allow the verification of the enforcement
+	 * of this value in drbg_healthcheck_sanity.
+	 */
+	return (SIZE_MAX - 1);
+#else
 	return (1UL<<(drbg->core->max_addtllen));
+#endif
 }
 
 static inline size_t drbg_max_requests(struct drbg_state *drbg)
 {
+#if (__BITS_PER_LONG == 32)
+	return SIZE_MAX;
+#else
 	return (1UL<<(drbg->core->max_req));
+#endif
 }
 
 /*

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

Re: [PATCH v2] DRBG: remove check for uninitialized DRBG handle

[Herbert Xu]

On Mon, Sep 01, 2014 at 07:11:20AM +0200, Stephan Mueller wrote:
> The drbg_healthcheck() contained a test to call the DRBG with an
> uninitialized DRBG cipher handle. As this is an inappropriate use of the
> kernel crypto API to try to generate random numbers before
> initialization, checks verifying for an initialized DRBG have been
> removed in previous patches.
> 
> Now, the drbg_healthcheck test must also be removed.
> 
> Changes V2: Added patch marker to email subject line.
> 
> Signed-off-by: Stephan Mueller <smueller@chronox.de>

Patch applied to crypto.  Thanks!
-- 
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

Re: [PATCH v2] DRBG: remove check for uninitialized DRBG handle

[Stephan Mueller]

Am Freitag, 5. September 2014, 15:55:49 schrieb Herbert Xu:

Hi Herbert,

>On Thu, Sep 04, 2014 at 01:50:32AM +0200, Stephan Mueller wrote:
>> Am Donnerstag, 4. September 2014, 07:21:29 schrieb Herbert Xu:
>> 
>> Hi Herbert,
>> 
>> > On Wed, Sep 03, 2014 at 03:33:16AM +0200, Stephan Mueller wrote:
>> > > Am Montag, 1. September 2014, 07:11:20 schrieb Stephan Mueller:
>> > > 
>> > > Hi Herbert,
>> > > 
>> > > may I ask for consideration of this patch as this covers an oops
>> > > FIPS
>> > > mode?
>> > > 
>> > > In addition, may I ask for guidance on how to fix the 32 bit code
>> > > path in Linus' tree as asked on 28.8? To quote: "Thus, the fix
>> > > in
>> > > b9347aff91ce4789619168539f08202d8d6a1177 works. However, this
>> > > patch is based on 05c81ccd9087d238c10b234eadb55632742e5518. So,
>> > > if we want to fix Linus' tree with minimal impact, either these
>> > > two patches are pushed to Linus or I have to port
>> > > b9347aff91ce4789619168539f08202d8d6a1177 to the current Linus
>> > > tree."
>> > 
>> > I will take care of this.
>> 
>> Thank you.
>
>Here is the patch I will add for 3.17:
>
>commit fb38ab4cd05e11184fd2c3ef916fa106ecc505fc
>Author: Herbert Xu <herbert@gondor.apana.org.au>
>Date:   Fri Sep 5 15:52:28 2014 +0800
>
>    crypto: drbg - backport "fix maximum value checks on 32 bit
>systems"
>
>    This is a backport of commit
>b9347aff91ce4789619168539f08202d8d6a1177. This backport is needed as
>without it the code will crash on 32-bit systems.

The kernel / module will not crash, It will simply refuse to work by 
always returning an error. I have tested the 3.17-rc1 code on 32 bit 
which returned always the error unless I apply this patch.
>
>    The maximum values for additional input string or generated blocks
>is larger than 1<<32. To ensure a sensible value on 32 bit systems,
>return SIZE_MAX on 32 bit systems. This value is lower than the
>maximum allowed values defined in SP800-90A. The standard allow lower
>maximum values, but not larger values.
>
>    SIZE_MAX - 1 is used for drbg_max_addtl to allow
>    drbg_healthcheck_sanity to check the enforcement of the variable
>    without wrapping.
>
>    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>    Reported-by: kbuild test robot <fengguang.wu@intel.com>
>    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
>diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
>index 831d786..882675e 100644
>--- a/include/crypto/drbg.h
>+++ b/include/crypto/drbg.h
>@@ -162,12 +162,25 @@ static inline size_t
>drbg_max_request_bytes(struct drbg_state *drbg)
>
> static inline size_t drbg_max_addtl(struct drbg_state *drbg)
> {
>+#if (__BITS_PER_LONG == 32)
>+	/*
>+	 * SP800-90A allows smaller maximum numbers to be returned -- we
>+	 * return SIZE_MAX - 1 to allow the verification of the 
enforcement
>+	 * of this value in drbg_healthcheck_sanity.
>+	 */
>+	return (SIZE_MAX - 1);
>+#else
> 	return (1UL<<(drbg->core->max_addtllen));
>+#endif
> }
>
> static inline size_t drbg_max_requests(struct drbg_state *drbg)
> {
>+#if (__BITS_PER_LONG == 32)
>+	return SIZE_MAX;
>+#else
> 	return (1UL<<(drbg->core->max_req));
>+#endif
> }
>
> /*
>
>Cheers,

Thank you very much!

Acked-by: Stephan Mueller <smueller@chronox.de>


Ciao
Stephan

linux-next: build warnings after merge of the crypto tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

Hi all,

After merging the crypto tree, today's linux-next build (htmldocs)
produced these warnings:

include/crypto/hash.h:69: error: Cannot parse struct or union!
include/crypto/hash.h:69: error: Cannot parse struct or union!
include/crypto/hash.h:245: warning: Function parameter or member 'HASH_ALG_COMMON' not described in 'shash_alg'
include/crypto/hash.h:69: error: Cannot parse struct or union!
include/crypto/hash.h:69: error: Cannot parse struct or union!
include/crypto/hash.h:69: error: Cannot parse struct or union!
include/crypto/hash.h:69: error: Cannot parse struct or union!
include/crypto/hash.h:69: error: Cannot parse struct or union!
include/crypto/hash.h:69: error: Cannot parse struct or union!

Introduced by commit

  0e4e6d7094df ("crypto: hash - Count error stats differently")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build warnings after merge of the crypto tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

Hi all,

After merging the crypto tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

scripts/Makefile.asm-generic:25: redundant generic-y found in arch/arm/include/asm/Kbuild: simd.h

Introduced by commit

  82cb54856874 ("asm-generic: make simd.h a mandatory include/asm header")

Also the powerpc ppc64_defconfig build produced this warning:

scripts/Makefile.asm-generic:25: redundant generic-y found in arch/powerpc/include/asm/Kbuild: simd.h

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build warnings after merge of the crypto tree

[Stephen Rothwell]

Hi Herbert,

On Sat, 11 Feb 2017 18:56:21 +0800 Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Fri, Feb 10, 2017 at 02:12:51PM +1100, Stephen Rothwell wrote:
> >
> > I am still getting these warnings ... I have seen no updates to the
> > crypot tree since Feb 2.  
> 
> Sorry Stephen.  I have now applied Arnd's fixes for this problem
> and it should be pushed out.

Thanks, its much cleaner now. :-)

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warnings after merge of the crypto tree

[Herbert Xu]

On Fri, Feb 10, 2017 at 02:12:51PM +1100, Stephen Rothwell wrote:
>
> I am still getting these warnings ... I have seen no updates to the
> crypot tree since Feb 2.

Sorry Stephen.  I have now applied Arnd's fixes for this problem
and it should be pushed out.

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

Re: linux-next: build warnings after merge of the crypto tree

[Stephen Rothwell]

Hi Herbert,

On Mon, 6 Feb 2017 17:03:40 +0800 Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Mon, Feb 06, 2017 at 12:28:37PM +1100, Stephen Rothwell wrote:
> > 
> > After merging the crypto tree, today's linux-next build (x86_64
> > allmodconfig) produced these warnings:
> > 
> > warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91)
> > warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91)
> > 
> > Introduced by commit
> > 
> >   89a82ef87e01 ("crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes")
> > 
> > In file included from include/linux/printk.h:329:0,
> >                  from include/linux/kernel.h:13,
> >                  from drivers/crypto/atmel-sha.c:17:  
> 
> This patch should fix both issues.  Thanks,

I am still getting these warnings ... I have seen no updates to the
crypot tree since Feb 2.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warnings after merge of the crypto tree

[Cyrille Pitchen]

Hi all,

Le 06/02/2017 à 02:28, Stephen Rothwell a écrit :
> Hi Herbert,
> 
> After merging the crypto tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
> 
> warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91)
> warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91)
> 
> Introduced by commit
> 
>   89a82ef87e01 ("crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes")
> 
> In file included from include/linux/printk.h:329:0,
>                  from include/linux/kernel.h:13,
>                  from drivers/crypto/atmel-sha.c:17:
> drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_cpu':
> drivers/crypto/atmel-sha.c:571:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
>   dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
>                    ^
> include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
>    __dynamic_dev_dbg(&descriptor, dev, fmt, \
>                                        ^
> drivers/crypto/atmel-sha.c:571:2: note: in expansion of macro 'dev_dbg'
>   dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
>   ^
> drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_pdc':
> drivers/crypto/atmel-sha.c:600:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
>   dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
>                    ^
> include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
>    __dynamic_dev_dbg(&descriptor, dev, fmt, \
>                                        ^
> drivers/crypto/atmel-sha.c:600:2: note: in expansion of macro 'dev_dbg'
>   dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
>   ^
> drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_dma':
> drivers/crypto/atmel-sha.c:647:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
>   dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
>                    ^
> include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
>    __dynamic_dev_dbg(&descriptor, dev, fmt, \
>                                        ^
> drivers/crypto/atmel-sha.c:647:2: note: in expansion of macro 'dev_dbg'
>   dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
>   ^
> drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_dma_map':
> drivers/crypto/atmel-sha.c:726:20: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
>    dev_err(dd->dev, "dma %u bytes error\n", ctx->buflen +
>                     ^
> In file included from include/linux/printk.h:329:0,
>                  from include/linux/kernel.h:13,
>                  from drivers/crypto/atmel-sha.c:17:
> drivers/crypto/atmel-sha.c: In function 'atmel_sha_update_dma_slow':
> drivers/crypto/atmel-sha.c:747:19: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'size_t {aka long unsigned int}' [-Wformat=]
>   dev_dbg(dd->dev, "slow: bufcnt: %u, digcnt: 0x%llx 0x%llx, final: %d\n",
>                    ^
> include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
>    __dynamic_dev_dbg(&descriptor, dev, fmt, \
>                                        ^
> drivers/crypto/atmel-sha.c:747:2: note: in expansion of macro 'dev_dbg'
>   dev_dbg(dd->dev, "slow: bufcnt: %u, digcnt: 0x%llx 0x%llx, final: %d\n",
>   ^
> drivers/crypto/atmel-sha.c: In function 'atmel_sha_update_dma_start':
> drivers/crypto/atmel-sha.c:775:19: warning: format '%u' expects argument of type 'unsigned int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
>   dev_dbg(dd->dev, "fast: digcnt: 0x%llx 0x%llx, bufcnt: %u, total: %u\n",
>                    ^
> include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
>    __dynamic_dev_dbg(&descriptor, dev, fmt, \
>                                        ^
> drivers/crypto/atmel-sha.c:775:2: note: in expansion of macro 'dev_dbg'
>   dev_dbg(dd->dev, "fast: digcnt: 0x%llx 0x%llx, bufcnt: %u, total: %u\n",
>   ^
> drivers/crypto/atmel-sha.c:817:21: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
>     dev_err(dd->dev, "dma %u bytes error\n",
>                      ^
> In file included from include/linux/printk.h:329:0,
>                  from include/linux/kernel.h:13,
>                  from drivers/crypto/atmel-sha.c:17:
> drivers/crypto/atmel-sha.c: In function 'atmel_sha_finish':
> drivers/crypto/atmel-sha.c:997:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
>   dev_dbg(dd->dev, "digcnt: 0x%llx 0x%llx, bufcnt: %d\n", ctx->digcnt[1],
>                    ^
> include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
>    __dynamic_dev_dbg(&descriptor, dev, fmt, \
>                                        ^
> drivers/crypto/atmel-sha.c:997:2: note: in expansion of macro 'dev_dbg'
>   dev_dbg(dd->dev, "digcnt: 0x%llx 0x%llx, bufcnt: %d\n", ctx->digcnt[1],
>   ^
> 
> I am not sure what caused this, but it may be that this code has not
> been built for this platform before?
> 


Indeed, the drivers/crypto/atmel-sha.c driver has never been built for x86_64.

CRYPTO_DEV_ATMEL_AUTHENC must select both CRYPTO_DEV_ATMEL_AES and
CRYPTO_DEV_ATMEL_SHA. I thought I could add a dependency to COMPILE_TEST
for CRYPTO_DEV_ATMEL_AUTHENC since CRYPTO_DEV_ATMEL_AES already had such a
dependency, hence could be compiled on architectures other than AT91 but I
didn't check the same for CRYPTO_DEV_ATMEL_SHA.

So maybe the easiest solution could be to remove the COMPILE_TEST
dependency on CRYPTO_DEV_ATMEL_AUTHENC for now, then I could try to fix all
these dev_dbg() format strings to make them become cross-platform compliant.

Herbert, if you think this solution is suitable I can prepare a first patch
to remove the COMPILE_TEST dependency on CRYPTO_DEV_ATMEL_AUTHENC.

Best regards,

Cyrille

Re: linux-next: build warnings after merge of the crypto tree

[Herbert Xu]

Hi Stephen:

On Mon, Feb 06, 2017 at 12:28:37PM +1100, Stephen Rothwell wrote:
> 
> After merging the crypto tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
> 
> warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91)
> warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91)
> 
> Introduced by commit
> 
>   89a82ef87e01 ("crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes")
> 
> In file included from include/linux/printk.h:329:0,
>                  from include/linux/kernel.h:13,
>                  from drivers/crypto/atmel-sha.c:17:

This patch should fix both issues.  Thanks,

---8<---
Subject: crypto: atmel - Fix authenc compile test warnings

The authenc code depends on the sha code so in order to allow
compile testing on the former we must allow it on sha as well.

This patch enables compile testing on sha as well as tdes and
fixes the few x86-64 warnings that arise in the sha code.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 7482461..9b7e19e 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -444,7 +444,7 @@ config CRYPTO_DEV_ATMEL_AES
 
 config CRYPTO_DEV_ATMEL_TDES
 	tristate "Support for Atmel DES/TDES hw accelerator"
-	depends on ARCH_AT91
+	depends on ARCH_AT91 || COMPILE_TEST
 	select CRYPTO_DES
 	select CRYPTO_BLKCIPHER
 	help
@@ -457,7 +457,7 @@ config CRYPTO_DEV_ATMEL_TDES
 
 config CRYPTO_DEV_ATMEL_SHA
 	tristate "Support for Atmel SHA hw accelerator"
-	depends on ARCH_AT91
+	depends on ARCH_AT91 || COMPILE_TEST
 	select CRYPTO_HASH
 	help
 	  Some Atmel processors have SHA1/SHA224/SHA256/SHA384/SHA512
diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel-sha.c
index 22d0c0c..b081e78 100644
--- a/drivers/crypto/atmel-sha.c
+++ b/drivers/crypto/atmel-sha.c
@@ -568,7 +568,7 @@ static int atmel_sha_xmit_cpu(struct atmel_sha_dev *dd, const u8 *buf,
 	int count, len32;
 	const u32 *buffer = (const u32 *)buf;
 
-	dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
+	dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %zu, final: %d\n",
 		ctx->digcnt[1], ctx->digcnt[0], length, final);
 
 	atmel_sha_write_ctrl(dd, 0);
@@ -597,7 +597,7 @@ static int atmel_sha_xmit_pdc(struct atmel_sha_dev *dd, dma_addr_t dma_addr1,
 	struct atmel_sha_reqctx *ctx = ahash_request_ctx(dd->req);
 	int len32;
 
-	dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
+	dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %zu, final: %d\n",
 		ctx->digcnt[1], ctx->digcnt[0], length1, final);
 
 	len32 = DIV_ROUND_UP(length1, sizeof(u32));
@@ -644,7 +644,7 @@ static int atmel_sha_xmit_dma(struct atmel_sha_dev *dd, dma_addr_t dma_addr1,
 	struct dma_async_tx_descriptor	*in_desc;
 	struct scatterlist sg[2];
 
-	dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
+	dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %zu, final: %d\n",
 		ctx->digcnt[1], ctx->digcnt[0], length1, final);
 
 	dd->dma_lch_in.dma_conf.src_maxburst = 16;
@@ -723,7 +723,7 @@ static int atmel_sha_xmit_dma_map(struct atmel_sha_dev *dd,
 	ctx->dma_addr = dma_map_single(dd->dev, ctx->buffer,
 				ctx->buflen + ctx->block_size, DMA_TO_DEVICE);
 	if (dma_mapping_error(dd->dev, ctx->dma_addr)) {
-		dev_err(dd->dev, "dma %u bytes error\n", ctx->buflen +
+		dev_err(dd->dev, "dma %zu bytes error\n", ctx->buflen +
 				ctx->block_size);
 		atmel_sha_complete(dd, -EINVAL);
 	}
@@ -744,7 +744,7 @@ static int atmel_sha_update_dma_slow(struct atmel_sha_dev *dd)
 
 	final = (ctx->flags & SHA_FLAGS_FINUP) && !ctx->total;
 
-	dev_dbg(dd->dev, "slow: bufcnt: %u, digcnt: 0x%llx 0x%llx, final: %d\n",
+	dev_dbg(dd->dev, "slow: bufcnt: %zu, digcnt: 0x%llx 0x%llx, final: %d\n",
 		 ctx->bufcnt, ctx->digcnt[1], ctx->digcnt[0], final);
 
 	if (final)
@@ -772,7 +772,7 @@ static int atmel_sha_update_dma_start(struct atmel_sha_dev *dd)
 	if (ctx->bufcnt || ctx->offset)
 		return atmel_sha_update_dma_slow(dd);
 
-	dev_dbg(dd->dev, "fast: digcnt: 0x%llx 0x%llx, bufcnt: %u, total: %u\n",
+	dev_dbg(dd->dev, "fast: digcnt: 0x%llx 0x%llx, bufcnt: %zu, total: %u\n",
 		ctx->digcnt[1], ctx->digcnt[0], ctx->bufcnt, ctx->total);
 
 	sg = ctx->sg;
@@ -814,7 +814,7 @@ static int atmel_sha_update_dma_start(struct atmel_sha_dev *dd)
 		ctx->dma_addr = dma_map_single(dd->dev, ctx->buffer,
 			ctx->buflen + ctx->block_size, DMA_TO_DEVICE);
 		if (dma_mapping_error(dd->dev, ctx->dma_addr)) {
-			dev_err(dd->dev, "dma %u bytes error\n",
+			dev_err(dd->dev, "dma %zu bytes error\n",
 				ctx->buflen + ctx->block_size);
 			atmel_sha_complete(dd, -EINVAL);
 		}
@@ -994,7 +994,7 @@ static int atmel_sha_finish(struct ahash_request *req)
 	if (ctx->digcnt[0] || ctx->digcnt[1])
 		atmel_sha_copy_ready_hash(req);
 
-	dev_dbg(dd->dev, "digcnt: 0x%llx 0x%llx, bufcnt: %d\n", ctx->digcnt[1],
+	dev_dbg(dd->dev, "digcnt: 0x%llx 0x%llx, bufcnt: %zu\n", ctx->digcnt[1],
 		ctx->digcnt[0], ctx->bufcnt);
 
 	return 0;
-- 
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

linux-next: build warnings after merge of the crypto tree

[Stephen Rothwell]

Hi Herbert,

After merging the crypto tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91)
warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91)

Introduced by commit

  89a82ef87e01 ("crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes")

In file included from include/linux/printk.h:329:0,
                 from include/linux/kernel.h:13,
                 from drivers/crypto/atmel-sha.c:17:
drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_cpu':
drivers/crypto/atmel-sha.c:571:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
  dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
                   ^
include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
   __dynamic_dev_dbg(&descriptor, dev, fmt, \
                                       ^
drivers/crypto/atmel-sha.c:571:2: note: in expansion of macro 'dev_dbg'
  dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
  ^
drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_pdc':
drivers/crypto/atmel-sha.c:600:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
  dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
                   ^
include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
   __dynamic_dev_dbg(&descriptor, dev, fmt, \
                                       ^
drivers/crypto/atmel-sha.c:600:2: note: in expansion of macro 'dev_dbg'
  dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
  ^
drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_dma':
drivers/crypto/atmel-sha.c:647:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
  dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
                   ^
include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
   __dynamic_dev_dbg(&descriptor, dev, fmt, \
                                       ^
drivers/crypto/atmel-sha.c:647:2: note: in expansion of macro 'dev_dbg'
  dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
  ^
drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_dma_map':
drivers/crypto/atmel-sha.c:726:20: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
   dev_err(dd->dev, "dma %u bytes error\n", ctx->buflen +
                    ^
In file included from include/linux/printk.h:329:0,
                 from include/linux/kernel.h:13,
                 from drivers/crypto/atmel-sha.c:17:
drivers/crypto/atmel-sha.c: In function 'atmel_sha_update_dma_slow':
drivers/crypto/atmel-sha.c:747:19: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'size_t {aka long unsigned int}' [-Wformat=]
  dev_dbg(dd->dev, "slow: bufcnt: %u, digcnt: 0x%llx 0x%llx, final: %d\n",
                   ^
include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
   __dynamic_dev_dbg(&descriptor, dev, fmt, \
                                       ^
drivers/crypto/atmel-sha.c:747:2: note: in expansion of macro 'dev_dbg'
  dev_dbg(dd->dev, "slow: bufcnt: %u, digcnt: 0x%llx 0x%llx, final: %d\n",
  ^
drivers/crypto/atmel-sha.c: In function 'atmel_sha_update_dma_start':
drivers/crypto/atmel-sha.c:775:19: warning: format '%u' expects argument of type 'unsigned int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
  dev_dbg(dd->dev, "fast: digcnt: 0x%llx 0x%llx, bufcnt: %u, total: %u\n",
                   ^
include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
   __dynamic_dev_dbg(&descriptor, dev, fmt, \
                                       ^
drivers/crypto/atmel-sha.c:775:2: note: in expansion of macro 'dev_dbg'
  dev_dbg(dd->dev, "fast: digcnt: 0x%llx 0x%llx, bufcnt: %u, total: %u\n",
  ^
drivers/crypto/atmel-sha.c:817:21: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
    dev_err(dd->dev, "dma %u bytes error\n",
                     ^
In file included from include/linux/printk.h:329:0,
                 from include/linux/kernel.h:13,
                 from drivers/crypto/atmel-sha.c:17:
drivers/crypto/atmel-sha.c: In function 'atmel_sha_finish':
drivers/crypto/atmel-sha.c:997:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
  dev_dbg(dd->dev, "digcnt: 0x%llx 0x%llx, bufcnt: %d\n", ctx->digcnt[1],
                   ^
include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
   __dynamic_dev_dbg(&descriptor, dev, fmt, \
                                       ^
drivers/crypto/atmel-sha.c:997:2: note: in expansion of macro 'dev_dbg'
  dev_dbg(dd->dev, "digcnt: 0x%llx 0x%llx, bufcnt: %d\n", ctx->digcnt[1],
  ^

I am not sure what caused this, but it may be that this code has not
been built for this platform before?

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warnings after merge of the crypto tree

[Herbert Xu]

On Tue, Mar 10, 2015 at 07:00:26PM -0700, Tadeusz Struk wrote:
> On 03/09/2015 11:03 PM, Herbert Xu wrote:
> > This is a bit of a bummer.  What happened is that net-next has
> > killed the kiocb argument to sendmsg/recvmsg.  However, this
> > change is obviously not part of the crypto tree and algif_aead
> > only exists in the crypto tree.
> > 
> > So Stephen could you fix this by hand until one of them is merged
> > upstream (just kill the first argument in aead_sendmsg/aead_recvmsg)?
> 
> So does it mean that aio operations will not be supported on sockets?

Indeed.  If you want to have this ability you'll need to take
the discussion over to netdev.

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

Re: linux-next: build warnings after merge of the crypto tree

[Tadeusz Struk]

On 03/09/2015 11:03 PM, Herbert Xu wrote:
> This is a bit of a bummer.  What happened is that net-next has
> killed the kiocb argument to sendmsg/recvmsg.  However, this
> change is obviously not part of the crypto tree and algif_aead
> only exists in the crypto tree.
> 
> So Stephen could you fix this by hand until one of them is merged
> upstream (just kill the first argument in aead_sendmsg/aead_recvmsg)?

So does it mean that aio operations will not be supported on sockets?

Re: linux-next: build warnings after merge of the crypto tree

[Herbert Xu]

On Wed, Mar 11, 2015 at 11:56:37AM +1100, Stephen Rothwell wrote:
> 
> This is what I applied:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 11 Mar 2015 11:51:30 +1100
> Subject: [PATCH] crypto: fix for sendmsg/recvmsg API change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Looks good to me.  Thanks Stephen!
-- 
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

Re: linux-next: build warnings after merge of the crypto tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2569 bytes --]

Hi all,

On Tue, 10 Mar 2015 17:44:54 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 10 Mar 2015 17:03:28 +1100 Herbert Xu <herbert@gondor.apana.org.au> wrote:
> >
> > On Tue, Mar 10, 2015 at 04:44:17PM +1100, Stephen Rothwell wrote:
> > > 
> > > After merging the crypto tree, today's (and the past few days)
> > > linux-next build (powerpc allyesconfig) produced these warnings:
> > > 
> > > crypto/algif_aead.c:561:2: warning: initialization from incompatible pointer type
> > >   .sendmsg = aead_sendmsg,
> > >   ^
> > > crypto/algif_aead.c:561:2: warning: (near initialization for 'algif_aead_ops.sendmsg')
> > > crypto/algif_aead.c:563:2: warning: initialization from incompatible pointer type
> > >   .recvmsg = aead_recvmsg,
> > >   ^
> > > crypto/algif_aead.c:563:2: warning: (near initialization for 'algif_aead_ops.recvmsg')
> > > 
> > > Introduced by commit 400c40cf78da ("crypto: algif - add AEAD support").
> > 
> > This is a bit of a bummer.  What happened is that net-next has
> > killed the kiocb argument to sendmsg/recvmsg.  However, this
> > change is obviously not part of the crypto tree and algif_aead
> > only exists in the crypto tree.
> > 
> > So Stephen could you fix this by hand until one of them is merged
> > upstream (just kill the first argument in aead_sendmsg/aead_recvmsg)?
> 
> No worries, I will put a merge fix patch in from tomorrow (and send you
> a copy just in case).

This is what I applied:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 11 Mar 2015 11:51:30 +1100
Subject: [PATCH] crypto: fix for sendmsg/recvmsg API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 crypto/algif_aead.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 527d27b023ab..001d8b5ad056 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -163,7 +163,7 @@ static void aead_data_wakeup(struct sock *sk)
 	rcu_read_unlock();
 }
 
-static int aead_sendmsg(struct kiocb *unused, struct socket *sock,
+static int aead_sendmsg(struct socket *sock,
 			struct msghdr *msg, size_t size)
 {
 	struct sock *sk = sock->sk;
@@ -348,7 +348,7 @@ unlock:
 	return err ?: size;
 }
 
-static int aead_recvmsg(struct kiocb *unused, struct socket *sock,
+static int aead_recvmsg(struct socket *sock,
 			struct msghdr *msg, size_t ignored, int flags)
 {
 	struct sock *sk = sock->sk;
-- 
2.1.4


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: build warnings after merge of the crypto tree

[Stephan Mueller]

Am Dienstag, 10. März 2015, 17:44:54 schrieb Stephen Rothwell:

Hi Stephen,

>Hi Herbert,
>
>On Tue, 10 Mar 2015 17:03:28 +1100 Herbert Xu 
<herbert@gondor.apana.org.au> wrote:
>> On Tue, Mar 10, 2015 at 04:44:17PM +1100, Stephen Rothwell wrote:
>> > After merging the crypto tree, today's (and the past few days)
>> > linux-next build (powerpc allyesconfig) produced these warnings:
>> > 
>> > crypto/algif_aead.c:561:2: warning: initialization from
>> > incompatible pointer type> > 
>> >   .sendmsg = aead_sendmsg,
>> >   ^
>> > 
>> > crypto/algif_aead.c:561:2: warning: (near initialization for
>> > 'algif_aead_ops.sendmsg') crypto/algif_aead.c:563:2: warning:
>> > initialization from incompatible pointer type> > 
>> >   .recvmsg = aead_recvmsg,
>> >   ^
>> > 
>> > crypto/algif_aead.c:563:2: warning: (near initialization for
>> > 'algif_aead_ops.recvmsg')
>> > 
>> > Introduced by commit 400c40cf78da ("crypto: algif - add AEAD
>> > support").> 
>> This is a bit of a bummer.  What happened is that net-next has
>> killed the kiocb argument to sendmsg/recvmsg.  However, this
>> change is obviously not part of the crypto tree and algif_aead
>> only exists in the crypto tree.
>> 
>> So Stephen could you fix this by hand until one of them is merged
>> upstream (just kill the first argument in aead_sendmsg/aead_recvmsg)?
>
>No worries, I will put a merge fix patch in from tomorrow (and send you
>a copy just in case).

Thank you. Let me know if I should help.


Ciao
Stephan

Re: linux-next: build warnings after merge of the crypto tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]

Hi Herbert,

On Tue, 10 Mar 2015 17:03:28 +1100 Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Tue, Mar 10, 2015 at 04:44:17PM +1100, Stephen Rothwell wrote:
> > 
> > After merging the crypto tree, today's (and the past few days)
> > linux-next build (powerpc allyesconfig) produced these warnings:
> > 
> > crypto/algif_aead.c:561:2: warning: initialization from incompatible pointer type
> >   .sendmsg = aead_sendmsg,
> >   ^
> > crypto/algif_aead.c:561:2: warning: (near initialization for 'algif_aead_ops.sendmsg')
> > crypto/algif_aead.c:563:2: warning: initialization from incompatible pointer type
> >   .recvmsg = aead_recvmsg,
> >   ^
> > crypto/algif_aead.c:563:2: warning: (near initialization for 'algif_aead_ops.recvmsg')
> > 
> > Introduced by commit 400c40cf78da ("crypto: algif - add AEAD support").
> 
> This is a bit of a bummer.  What happened is that net-next has
> killed the kiocb argument to sendmsg/recvmsg.  However, this
> change is obviously not part of the crypto tree and algif_aead
> only exists in the crypto tree.
> 
> So Stephen could you fix this by hand until one of them is merged
> upstream (just kill the first argument in aead_sendmsg/aead_recvmsg)?

No worries, I will put a merge fix patch in from tomorrow (and send you
a copy just in case).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: build warnings after merge of the crypto tree

[Herbert Xu]

On Tue, Mar 10, 2015 at 04:44:17PM +1100, Stephen Rothwell wrote:
> Hi Herbert,
> 
> After merging the crypto tree, today's (and the past few days)
> linux-next build (powerpc allyesconfig) produced these warnings:
> 
> crypto/algif_aead.c:561:2: warning: initialization from incompatible pointer type
>   .sendmsg = aead_sendmsg,
>   ^
> crypto/algif_aead.c:561:2: warning: (near initialization for 'algif_aead_ops.sendmsg')
> crypto/algif_aead.c:563:2: warning: initialization from incompatible pointer type
>   .recvmsg = aead_recvmsg,
>   ^
> crypto/algif_aead.c:563:2: warning: (near initialization for 'algif_aead_ops.recvmsg')
> 
> Introduced by commit 400c40cf78da ("crypto: algif - add AEAD support").

This is a bit of a bummer.  What happened is that net-next has
killed the kiocb argument to sendmsg/recvmsg.  However, this
change is obviously not part of the crypto tree and algif_aead
only exists in the crypto tree.

So Stephen could you fix this by hand until one of them is merged
upstream (just kill the first argument in aead_sendmsg/aead_recvmsg)?

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

linux-next: build warnings after merge of the crypto tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

Hi Herbert,

After merging the crypto tree, today's (and the past few days)
linux-next build (powerpc allyesconfig) produced these warnings:

crypto/algif_aead.c:561:2: warning: initialization from incompatible pointer type
  .sendmsg = aead_sendmsg,
  ^
crypto/algif_aead.c:561:2: warning: (near initialization for 'algif_aead_ops.sendmsg')
crypto/algif_aead.c:563:2: warning: initialization from incompatible pointer type
  .recvmsg = aead_recvmsg,
  ^
crypto/algif_aead.c:563:2: warning: (near initialization for 'algif_aead_ops.recvmsg')

Introduced by commit 400c40cf78da ("crypto: algif - add AEAD support").
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]