On Sun, 3 Aug 2025 12:00:38 +0200 Michal Luczaj wrote:

On 7/31/25 03:02, Jakub Kicinski wrote:

quoted

On Fri, 25 Jul 2025 12:33:04 +0200 Michal Luczaj wrote:  

quoted

Flags passed in for splice() syscall should not end up in
skb_recv_datagram(). As SPLICE_F_NONBLOCK == MSG_PEEK, kernel gets
confused: skb isn't unlinked from a receive queue, while strp_msg::offset
and strp_msg::full_len are updated.

Unbreak the logic a bit more by mapping both O_NONBLOCK and
SPLICE_F_NONBLOCK to MSG_DONTWAIT. This way we align with man splice(2) in
regard to errno EAGAIN:

   SPLICE_F_NONBLOCK was specified in flags or one of the file descriptors
   had been marked as nonblocking (O_NONBLOCK), and the operation would
   block.  

Coincidentally looks like we're not honoring

	sock->file->f_flags & O_NONBLOCK 

in TLS..  

I'm a bit confused.

Comparing AF_UNIX and pure (non-TLS) TCP, I see two non-blocking-splice
interpretations. Unix socket doesn't block on `f_flags & O_NONBLOCK ||
flags & SPLICE_F_NONBLOCK` (which this patch follows), while TCP, after
commit 42324c627043 ("net: splice() from tcp to pipe should take into
account O_NONBLOCK"), honours O_NONBLOCK and ignores SPLICE_F_NONBLOCK.

Should KCM (and TLS) follow TCP behaviour instead?

I didn't look closely, but FWIW - yes, in principle KCM and TLS should
copy TCP.