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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux