Am Donnerstag, 22. Februar 2018, 14:06:00 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Feb 09, 2018 at 11:02:27PM +0100, Stephan Müller wrote: > > Hi, > > > > Herbert, the patch 1 is meant for stable. However, this patch as is > > only applies to the new AF_ALG interface implementation. Though, > > the issue goes back to the first implementation of AIO support. > > Shall I try prepare a patch for the old AF_ALG implementation > > as well? > > I think this is overcomplicated. We simply need to duplicate > the IV for async operations. That is, if you're doing an async > recvmsg then the IV must be duplicated and stored in the request > instead of the global context. A simple copy operation, however, will imply that in one AIO recvmsg request, only *one* IOCB can be set and processed. If multiple IOCBs are processed, then each IOCB would get the same IV with the same key, just different plain/ciphertext. With this approach, I think we neither support a fully parallel execution of independent cipher operations (as suppgested with the inline IV patch that requires the caller to provide a separate IV for each recvmsg call) nor a serialized operation of multiple IOCBs where the IV-based block chaining links the different dependent IOBCs. Therefore, I would think that between each recvmsg call with one IOCB another sendmsg must be made to set the IV in order to support either of the aforementioned scenarios (parallel and serialized). IMHO this seems to be a waste of resources. > > Remember, you must not start the sendmsg for the next request > until the recvmsg system call for the previous request has completed. I understand that, but one AIO recvmsg can process multiple cipher operations all at once (one IOCB defines one operation). Otherwise we do not utilize the true potential of the AIO support. We would use the AIO support to mimic synchronous behavior. > > Cheers, Ciao Stephan
