[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b6a2219b-32dd-4bb6-b848-45325e4e4ab9@rbox.co>
Date: Sun, 3 Aug 2025 12:00:38 +0200
From: Michal Luczaj <mhal@...x.co>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
Simon Horman <horms@...nel.org>, Cong Wang <cong.wang@...edance.com>,
Tom Herbert <tom@...bertland.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] kcm: Fix splice support
On 7/31/25 03:02, Jakub Kicinski wrote:
> On Fri, 25 Jul 2025 12:33:04 +0200 Michal Luczaj wrote:
>> 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?
Thanks,
Michal
Powered by blists - more mailing lists