On 5/23/2019 3:38 PM, Herbert Xu wrote:
> On Thu, May 23, 2019 at 10:02:41AM +, Horia Geanta wrote:
>>
>> When crypto_register_akcipher fails, it merely prints a warning and falls
>> through (does not immediately return), thus there's no leak.
>
> How can this work? Wouldn't the exit path then
Ping!!
> -Original Message-
> From: Kalyani Akula
> Sent: Wednesday, May 8, 2019 3:01 PM
> To: Stephan Mueller
> Cc: herb...@gondor.apana.org.au; da...@davemloft.net; linux-
> cry...@vger.kernel.org; linux-ker...@vger.kernel.org; Sarat Chand Savitala
>
> Subject: RE: [RFC PATCH 4/5] cryp
Hi Pascal,
Le 23/05/2019 à 23:43, Pascal Van Leeuwen a écrit :
-Original Message-
From: Eric Biggers [mailto:ebigg...@kernel.org]
[...]
Note that it's not necessary that your *hardware* supports empty messages,
since you can simply do this in the driver instead:
if (req->cryp
On Thu, May 23, 2019 at 4:06 PM Eric Biggers wrote:
>
> On Thu, May 23, 2019 at 01:07:25PM +, Pascal Van Leeuwen wrote:
> >
> > I'm running into some trouble with some random vectors that do *zero*
> > length operations. Now you can go all formal about how the API does
> > not explictly disall
On Thu, 23 May 2019 at 22:44, Pascal Van Leeuwen
wrote:
>
> > -Original Message-
> > From: Eric Biggers [mailto:ebigg...@kernel.org]
> > Sent: Thursday, May 23, 2019 10:06 PM
> > To: Pascal Van Leeuwen
> > Cc: linux-crypto@vger.kernel.org
> > Subject: Re: another testmgr question
> >
> >
On Thu, May 23, 2019 at 09:43:53PM +, Pascal Van Leeuwen wrote:
> > -Original Message-
> > From: Eric Biggers [mailto:ebigg...@kernel.org]
> > Sent: Thursday, May 23, 2019 10:06 PM
> > To: Pascal Van Leeuwen
> > Cc: linux-crypto@vger.kernel.org
> > Subject: Re: another testmgr question
> -Original Message-
> From: Eric Biggers [mailto:ebigg...@kernel.org]
> Sent: Thursday, May 23, 2019 10:06 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: another testmgr question
>
> On Thu, May 23, 2019 at 01:07:25PM +, Pascal Van Leeuwen wrote:
> > Eri
On Thu, May 23, 2019 at 07:44:08PM +, Pascal Van Leeuwen wrote:
> > -Original Message-
> > From: Eric Biggers [mailto:ebigg...@google.com]
> > Sent: Thursday, May 23, 2019 9:06 PM
> > To: Pascal Van Leeuwen
> > Cc: linux-crypto-ow...@vger.kernel.org; Herbert Xu
> >
> > Subject: Re: te
On Thu, May 23, 2019 at 01:07:25PM +, Pascal Van Leeuwen wrote:
> Eric,
>
> I'm running into some trouble with some random vectors that do *zero*
> length operations. Now you can go all formal about how the API does
> not explictly disallow this, but how much sense does it really make
> to esse
> -Original Message-
> From: Eric Biggers [mailto:ebigg...@google.com]
> Sent: Thursday, May 23, 2019 9:06 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto-ow...@vger.kernel.org; Herbert Xu
>
> Subject: Re: testmgr question
>
> On Thu, May 23, 2019 at 07:01:46AM +, Pascal Van Leeuwen wr
> -Original Message-
> From: Eric Biggers [mailto:ebigg...@google.com]
> Sent: Thursday, May 23, 2019 8:59 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto-ow...@vger.kernel.org
> Subject: Re: another testmgr question
>
> On Thu, May 23, 2019 at 01:07:25PM +, Pascal Van Leeuwen wrote:
>
On Thu, May 23, 2019 at 10:02:41AM +, Horia Geanta wrote:
>
> When crypto_register_akcipher fails, it merely prints a warning and falls
> through (does not immediately return), thus there's no leak.
How can this work? Wouldn't the exit path then unregister a bunch of
unregistered algorithms an
On 5/23/2019 11:50 AM, Sascha Hauer wrote:
> The CAAM driver has most of its debug messages inside #ifdef DEBUG and
> then prints them at KERN_ERR level. Do this properly and print the
> messages at DEBUG_LEVEL as they are supposed to. With this we can get
> rid of a lot of ifdefs in the code.
>
T
On 5/23/2019 9:12 AM, Herbert Xu wrote:
> On Wed, May 15, 2019 at 02:25:45PM +0300, Iuliana Prodan wrote:
>>
>> @@ -1058,6 +1105,14 @@ static int __init caam_pkc_init(void)
>> goto out_put_dev;
>> }
>>
>> +/* allocate zero buffer, used for padding input */
>> +zero_buffe
The CAAM driver has most of its debug messages inside #ifdef DEBUG and
then prints them at KERN_ERR level. Do this properly and print the
messages at DEBUG_LEVEL as they are supposed to. With this we can get
rid of a lot of ifdefs in the code.
Sascha
Changes since v1:
- Fix alignment on following
Since eaed71a44ad9 ("crypto: caam - add ecb(*) support") the IV can be
NULL, so only dump it when it's non NULL as designated by the ivsize
variable.
Fixes: eaed71a44ad9 ("crypto: caam - add ecb(*) support")
Signed-off-by: Sascha Hauer
---
drivers/crypto/caam/caamalg.c | 7 ---
1 file change
The CAAM driver used to put its debug messages inside #ifdef DEBUG and
then prints the messages at KERN_ERR level. Replace this with proper
functions printing at KERN_DEBUG level. The #ifdef DEBUG gets
unnecessary when the right functions are used.
This replaces:
- print_hex_dump(KERN_ERR ...) in
caam_dump_sg() is only compiled in when DEBUG is defined, hence the
messages are debug messages. Remove the @level argument from
caam_dump_sg() and print all messages at debug level.
Signed-off-by: Sascha Hauer
---
drivers/crypto/caam/caamalg.c | 8
drivers/crypto/caam/caamalg_qi.c
The CAAM driver defines its own debug() macro, but it is unused. Remove
it.
Signed-off-by: Sascha Hauer
Reviewed-by: Horia Geantă
---
drivers/crypto/caam/caamalg.c | 7 ---
drivers/crypto/caam/caamhash.c | 8
2 files changed, 15 deletions(-)
diff --git a/drivers/crypto/caam/caama
On 5/23/2019 9:12 AM, Herbert Xu wrote:
> On Wed, May 15, 2019 at 02:25:45PM +0300, Iuliana Prodan wrote:
>>
>> @@ -1058,6 +1105,14 @@ static int __init caam_pkc_init(void)
>> goto out_put_dev;
>> }
>>
>> +/* allocate zero buffer, used for padding input */
>> +zero_buff
21 matches
Mail list logo
