On Wed, 2014-05-21 at 21:05 +0800, Herbert Xu wrote: > On Thu, May 15, 2014 at 11:12:03AM -0700, Tim Chen wrote: > > > > > In which case your patch would basically do kmap if ASYNC and > > > kmap_atomic otherwise. > > > > > > I'll try to make such a patch. > > Please see attached. > > It will be nice if scatterwalk_map and unmap can also be made > > async aware. Right now it also uses kmap_atomic. > > This will allow multi-buffer encryption to make use of it. > > Is this for ciphers? Could you use ablkcipher_walk since it doesn't > actually map anything meaning that you can map it yourself? > > commit 75ecb231ff45b54afa9f4ec9137965c3c00868f4 > Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > Date: Wed May 21 20:56:12 2014 +0800 > > crypto: hash - Add real ahash walk interface > > Although the existing hash walk interface has already been used > by a number of ahash crypto drivers, it turns out that none of > them were really asynchronous. They were all essentially polling > for completion. > > That's why nobody has noticed until now that the walk interface > couldn't work with a real asynchronous driver since the memory > is mapped using kmap_atomic. > > As we now have a use-case for a real ahash implementation on x86, > this patch creates a minimal ahash walk interface. Basically it > just calls kmap instead of kmap_atomic and does away with the > crypto_yield call. Real ahash crypto drivers don't need to yield > since by definition they won't be hogging the CPU. > > Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > Herbert, Thanks for the patch. I'll test it out for multi-buffer sha1 and then send out an update of the patch series. 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