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

[Matt Whitlock <kernel@mattwhitlock.name>]

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).