linux-kernel - Re: [RFC PATCH 00/31] netfs: [WIP] Allow the use of MSG_SPLICE

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <40d1f78c-d437-4ab4-8e5e-8708af6486ab@samba.org>
Date: Thu, 7 Aug 2025 08:54:20 +0200
From: Stefan Metzmacher <metze@...ba.org>
To: David Howells <dhowells@...hat.com>
Cc: Steve French <sfrench@...ba.org>, Paulo Alcantara <pc@...guebit.org>,
 Shyam Prasad N <sprasad@...rosoft.com>, Tom Talpey <tom@...pey.com>,
 Wang Zhaolong <wangzhaolong@...weicloud.com>,
 Mina Almasry <almasrymina@...gle.com>, linux-cifs@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 00/31] netfs: [WIP] Allow the use of MSG_SPLICE_PAGES
 and use netmem allocator

Am 07.08.25 um 08:24 schrieb David Howells:
> Stefan Metzmacher <metze@...ba.org> wrote:
> 
>> So the current situation is that we memcpy (at least) in sendmsg()
>> and with your patches we do a memcpy higher in the stack, but then
>> use MSG_SPLICE_PAGES in order to do it twice. Is that correct?
> 
> Not twice, no.  MSG_SPLICE_PAGES allows sendmsg() to splice the supplied pages
> into the sk_buffs directly, thereby avoiding a copy in the TCP layer and
> cutting out the feeder loop in cifs.

Yes, and we must be careful to not touch the pages after
calling sendmsg(MSG_SPLICE_PAGES).

And unlike MSG_ZEROCOPY tcp_sendmsg_locked() has no
no struct ubuf_info *uarg when MSG_SPLICE_PAGES is used
and there's no way to know when the pages are no longer
used by the tcp stack.

Can you explain how/where we allocate the memory and where
we unreference it in the caller of sendmsg(MSG_SPLICE_PAGES).

> However, this is meant to be an intermediate step.  I actually want to
> assemble the fragment list in a bvecq in the smb_create_request() as called by
> the PDU encoders, with everything aligned for crypto so that the crypto layer
> doesn't copy it also.  But cleaning up the transport first should hopefully
> reduce the size of the later patches.

Sounds good :-)

metze