lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <54f5b076-4648-4d2b-b50b-e775c4ddb4bf@rbox.co>
Date: Wed, 6 Aug 2025 23:15:22 +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 8/5/25 01:51, Jakub Kicinski wrote:
> On Sun, 3 Aug 2025 12:00:38 +0200 Michal Luczaj wrote:
>> 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?
> 
> I didn't look closely, but FWIW - yes, in principle KCM and TLS should
> copy TCP.

Ugh, so this KCM patch is incorrect. Sorry, I'll submit a follow up
tweaking KCM and TLS, as suggested.

Note about SPLICE_F_NONBLOCK: besides AF_UNIX, it is also honoured in
AF_SMC and tracefs.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ