On Sun, Dec 25, 2016 at 06:15:06PM +0100, Stephan Müller wrote: > > + * The following concept of the memory management is used: > + * > + * The kernel maintains two SGLs, the TX SGL and the RX SGL. The TX SGL is > + * filled by user space with the data submitted via sendpage/sendmsg. Filling > + * up the TX SGL does not cause a crypto operation -- the data will only be > + * tracked by the kernel. Upon receipt of one recvmsg call, the caller must > + * provide a buffer which is tracked with the RX SGL. > + * > + * During the processing of the recvmsg operation, the cipher request is > + * allocated and prepared. To support multiple recvmsg operations operating > + * on one TX SGL, an offset pointer into the TX SGL is maintained. The TX SGL > + * that is used for the crypto request is scatterwalk_ffwd by the offset > + * pointer to obtain the start address the crypto operation shall use for > + * the input data. I think this is overcomplicating things. The async interface should be really simple. It should be exactly the same as the sync interface, except that completion is out-of-line. So there should be no mixing of SGLs from different requests. Just start with a clean slate after each recvmsg regardless of whether it's sync or async. The only difference in the async case is that you need to keep a reference to the old pages and free them upon completion. But this should in no way interfere with subsequent requests. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
