linux-kernel - Re: [RFC -next 00/10] Add ZC notifications to splice and sendfile

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z92VkgwS1SAaad2Q@LQ3V64L9R2>
Date: Fri, 21 Mar 2025 09:36:34 -0700
From: Joe Damato <jdamato@...tly.com>
To: Jens Axboe <axboe@...nel.dk>
Cc: Christoph Hellwig <hch@...radead.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, asml.silence@...il.com,
	linux-fsdevel@...r.kernel.org, edumazet@...gle.com,
	pabeni@...hat.com, horms@...nel.org, linux-api@...r.kernel.org,
	linux-arch@...r.kernel.org, viro@...iv.linux.org.uk, jack@...e.cz,
	kuba@...nel.org, shuah@...nel.org, sdf@...ichev.me,
	mingo@...hat.com, arnd@...db.de, brauner@...nel.org,
	akpm@...ux-foundation.org, tglx@...utronix.de, jolsa@...nel.org,
	linux-kselftest@...r.kernel.org
Subject: Re: [RFC -next 00/10] Add ZC notifications to splice and sendfile

On Fri, Mar 21, 2025 at 05:14:59AM -0600, Jens Axboe wrote:
> On 3/20/25 11:56 PM, Christoph Hellwig wrote:
> >> I don't know the entire historical context, but I presume sendmsg
> >> did that because there was no other mechanism at the time.
> > 
> > At least aio had been around for about 15 years at the point, but
> > networking folks tend to be pretty insular and reinvent things.
> 
> Yep...
> 
> >> It seems like Jens suggested that plumbing this through for splice
> >> was a possibility, but sounds like you disagree.
> > 
> > Yes, very strongly.
> 
> And that is very much not what I suggested, fwiw.

Your earlier message said:

  If the answer is "because splice", then it would seem saner to
  plumb up those bits only. Would be much simpler too...

wherein I interpreted "plumb those bits" to mean plumbing the error
queue notifications on TX completions.

My sincere apologies that I misunderstood your prior message and/or
misconstrued what you said -- it was not clear to me what you meant.

It is clear to me now, though, that adding a flag to splice as
previously proposed and extending sendfile based on the SO_ZEROCOPY
sock flag being set are both unacceptable solutions.

If you happen to have a suggestion of some piece of code that I
should read (other than the iouring implementation) to inform how I
might build an RFCv2, I would appreciate the pointer.

Thanks for your time and energy,
Joe