On Thu, 2015-11-19 at 08:12 +0800, Herbert Xu wrote: > On Wed, Nov 18, 2015 at 07:58:56AM -0800, Tim Chen wrote: > > > > IPSec will invoke this multi-buffer encrypt with async request. > > The work is done in crypto daemon, so it wouldn't be in atomic > > context. But anyway, I'm okay with switching to ablkcipher walk, > > as long as it doesn't incur too much more overhead than blkcipher > > walk. > > What if some other user called the blkcipher interface in an atomic > context? You can't guarantee that your algorithm is only picked up > through the ablkcipher interface, unless of course you do something > like __driver-ctr-aes-aesni. 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. 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. > > Hmm I was just looking at the sha_mb code and something doesn't > look right. For instance, can sha1_mb_update ever return > -EINPROGRESS? This would be wrong as it's registered as an shash > algorithm. 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. Tim -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
