On Wed, 2014-05-14 at 07:58 +0800, Herbert Xu wrote: > On Tue, May 13, 2014 at 04:40:58PM -0700, Tim Chen wrote: > > On Wed, 2014-05-14 at 07:34 +0800, Herbert Xu wrote: > > > > > > > > Why do we need this patch since kmap_atomic is equivalent to > > > page_address plus preempt_disable on x86-64? > > > > For multi-buffers, you may still have some data lanes with jobs > > that are partially completed when you need to put the thread > > to sleep. With kmap_atomic, you cannot sleep before unmapping. > > Hmm, it seems that the existing users of this helper is abusing > the ahash interface since if they were really asynchronous they > would be sleeping on this kmap_atomic. The multi-buffer case certainly ran into trouble with kmap_atomic. The scheduler complains when the crypto thread schedules out. > > So we should keep the existing hash walk interface for sync users > only and create a new interface for async users. They could in > fact share the same underlying code and use the ASYNC bit to > indicate that we're async. > > In which case your patch would basically do kmap if ASYNC and > kmap_atomic otherwise. > > I'll try to make such a patch. 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. > > Eventually the existing users (which appear to be polling) should > either be converted over to shash or switch to interrupt-based > completion. Thanks. 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
