On Wed, Jul 19, 2023 at 09:35:33PM +0200, Miklos Szeredi wrote: > On Wed, 19 Jul 2023 at 19:59, Matt Whitlock <kernel@xxxxxxxxxxxxxxxxx> wrote: > > > > On Wednesday, 19 July 2023 06:17:51 EDT, Miklos Szeredi wrote: > > > On Thu, 29 Jun 2023 at 17:56, David Howells <dhowells@xxxxxxxxxx> wrote: > > >> > > >> Splicing data from, say, a file into a pipe currently leaves the source > > >> pages in the pipe after splice() returns - but this means that those pages > > >> can be subsequently modified by shared-writable mmap(), write(), > > >> fallocate(), etc. before they're consumed. > > > > > > What is this trying to fix? The above behavior is well known, so > > > it's not likely to be a problem. > > > > Respectfully, it's not well-known, as it's not documented. If the splice(2) > > man page had mentioned that pages can be mutated after they're already > > ostensibly at rest in the output pipe buffer, then my nightly backups > > wouldn't have been incurring corruption silently for many months. > > splice(2): > > Though we talk of copying, actual copies are generally avoided. > The kernel does this by implementing a pipe buffer as a set of > refer‐ > ence-counted pointers to pages of kernel memory. The > kernel creates "copies" of pages in a buffer by creating new pointers > (for the > output buffer) referring to the pages, and increasing the > reference counts for the pages: only pointers are copied, not the > pages of the > buffer. > > While not explicitly stating that the contents of the pages can change > after being spliced, this can easily be inferred from the above > semantics. So what's the API that provides the semantics of _copying_? And, frankly, this is a "you're holding it wrong" kind of argument. It only makes sense if you're read the implementation, which is at best level 2: https://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html and worst a level -5: https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html
