writev(), IORING_OP_SPLICE and TCP_CORK issues

[markpapadakis]

Suppose that a sender:

1. set IPPROTO_TCP/TCP_CORK on a socket FD fd1
2. writev() 2 bytes to fd1
3. use io_uring_prep_splice() /w SPLICE_F_MOVE | SPLICE_F_NONBLOCK to copy/move some(say all but 1) byte in a pipe to fd1 ( bytesout 1)
4. unset PPROTO_TCP/TCP_CORK on fd1
5. io_uring_submit()
6. use io_uring_prep_splice() /w SPLICE_F_MOVE | SPLICE_F_NONBLOCK to copy/move all remaining bytes in the pipe (say, 1 byte) to fd1 (bytes_out_2)
7. io_uring_submit()

the receiver then reads()s:

1. 2 + bytes_out_1 bytes from read() ( read1 )
2. 2 + bytes_out_2 bytes from read() ( read2 )

Effectively, the 2 extra bytes received in read2 are those that were writev()-ed initially and were already received in read1. Somehow those are duplicated in the kernel (or it looks like they are).

• If I do not use a TCP_CORK for ( write(), io_uring_prep_splice(), io_uring_submit() ), the problem doesn't materialise (i.e read2 gets just bytes_out_2_bytes without that duplicated 2 bytes)
• If the first io_uring_prep_splice() while cork is set copies/moves ALL (as in not all but 1 or however many bytes) bytes available in the pipe, it also works

So it only fails if the above scenario plays out.

[markpapadakis]

UPDATE: use of SPLICE_F_MOVE makes no difference; fails either way.

[markpapadakis]

UPDATE: turns out this is not io-uring specific; using writev()/splice() directly results in the same issue. Maybe its a kernel issue, or maybe I am ignoring some specifics related to the use of corks and splice.

[axboe]

Closing this one, as it's not a liburing/io_uring issue. You may want to write a test case and report it to the linux kernel mailing list. Though I'm unsure of how maintained splice is these days...