lkml.org 
[lkml]   [2015]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure support
On Wed, Nov 18, 2015 at 06:39:30PM -0800, Tim Chen wrote:
>
> The __cbc-aes-aesni-mb algorithm is marked as internal algorithm
> with flag CRYPTO_ALG_INTERNAL, so it should not be picked up by other
> algorithms and should only be invoked from mcryptd.

OK I guess that's fine then.

> Anyway, I've udpated the aes_cbc_mb code with ablkcipher helper.
> So I will be posting the new series with ablkcipher walk
> after testing is done.

Yes I think what you have is a very special case. As you said
the ablkcipher interface should be fairly low in overhead so I
think it makes sense to use that instead of blkcipher.

> The __sha1-mb works in tandem with the outer layer of mcryptd
> aysnc algorithm. It does the completion for the outer
> async algorithm. So as far as mcryptd is concerned, the
> inner algorithm is synchronous in the sense that it is done
> once it dispatch the job to __sha1-mb and don't have to worry about it.
> I don't think mcryptd check for the return value from __sha1-mb
> so it should be okay to return 0 instead of -EINPROGRESS.
> I'll double check that.

If it can never return EINPROGRESS then we should probably remove
the code in it that says "return -EINPROGRESS".

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


\
 
 \ /
  Last update: 2015-11-19 11:01    [W:0.064 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site