Re: [RFC PATCH 1/4] splice: Fix corruption of spliced data after splice() returns

[Matt Whitlock]

On Wednesday, 19 July 2023 19:20:32 EDT, Linus Torvalds wrote:
> > On Wednesday, 19 July 2023 16:16:07 EDT, Linus Torvalds wrote:
> > > The *ONLY* reason for splice() existing is for zero-copy.
> >
> > The very first sentence of splice(2) reads: "splice() moves data between
> > two file descriptors without copying between kernel address space and user
> > address space." Thus, it is not unreasonable to believe that the point of
> > splice is to avoid copying between user-space and kernel-space.
>
> I'm not at all opposed to clarifying the documentation.

Then that is my request. This entire complaint/discussion/argument would 
have been avoided if splice(2) had contained a sentence like this one from 
sendfile(2):

"If out_fd refers to a socket or pipe with zero-copy support, callers must 
ensure the transferred portions of the file referred to by in_fd remain 
unmodified until the reader on the other end of out_fd has consumed the 
transferred data."

That is a clear warning of the perils of the implementation under the hood, 
and it could/should be copied, more or less verbatim, to splice(2).