On Fri, Jan 13, 2017 at 12:10:02PM +0100, Stephan Müller wrote: > > > 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. Are you making separate read calls or just a single one? If you're making separate calls, then this is no differnt to just doing write/read pairs. You're not saving any overhead. If you're making a single call, what guarantees the ordering? 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
