From: David Howells > Sent: 30 May 2023 23:27 > > Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > > Will the TLS selftests under tools/.../net/tls.c exercise this? > > Interesting. Now that you've pointed me at it, I've tried running it. Mostly > it passes, but I'm having some problems with the multi_chunk_sendfile tests > that time out. I think that splice_direct_to_actor() has a bug. The problem > is this bit of code: > > /* > * If more data is pending, set SPLICE_F_MORE > * If this is the last data and SPLICE_F_MORE was not set > * initially, clears it. > */ > if (read_len < len) > sd->flags |= SPLICE_F_MORE; > else if (!more) > sd->flags &= ~SPLICE_F_MORE; > > When used with sendfile(), it sets SPLICE_F_MORE (which causes MSG_MORE to be > passed to the network protocol) if we haven't yet read everything that the > user requested and clears it if we fulfilled what the user requested. > > This has the weird effect that MSG_MORE gets kind of inverted. It's never > seen by the actor if we can read the entire request into the pipe - except if > we hit the EOF first. If we hit the EOF before we fulfil the entire request, > we get a short read and SPLICE_F_MORE and thus MSG_MORE *is* set. The > upstream TLS code ignores it - but I'm changing this with my patches as > sendmsg() then uses it to mark the EOR. Isn't MSG_MORE supposed to be just a hint that more data will follow. So you'd expect a final send with MSG_MORE to get sent, but possibly after a short timeout. Using it as a record marker seems wrong. I'm not sure how to clear 'Oh bugger I set MSG_MORE but have no data' to avoid the timeout. A zero length semdmsg() won't DTRT with protocols like SCTP. (Does splice even do anything sensible with SCTP?) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
