Am Freitag, 13. Januar 2017, 19:03:35 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 13, 2017 at 11:49:05AM +0100, Stephan Müller wrote: > > According to the man page of lio_listio(3) the provided AIO operations are > > executed in an unspecified order. I would infer from that statement that > > even if an order of write / read / write / read is defined by the caller, > > this order may not be followed by the kernel. Thus we would need to > > consider the case that in the end, algif has to process the order of > > write / write / read / read or any other order. > > Well if ordering is not guaranteed that I don't see how your code > can work either. Or am I missing something? The patch simply stores all data it gets from sendmsg in the src SGL. In addition it maintains an offset pointer into that src SGLs. When the recvmsg call comes in and the dst SGL is prepared, it simply takes as much data from the src SGL as needed to cover the request defined by the dst SGL. After completing that operation, the offset pointer is moved forward to point to a yet unused part of the src SGL. If another recvmsg comes in without an intermediate sendmsg, it simply starts using the data from the src SGL starting from the offset. Therefore, the code should now be able to handle a write / write / read / read scenario. Or it can handle, say, a write(32 bytes) / read (16 bytes) / read (16 bytes). At least my tests covered a successful testing of that scenario which always crashed the kernel before. Ciao Stephan -- 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
