From: Linus Torvalds <torvalds@linux-foundation.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Matt Whitlock <kernel@mattwhitlock.name>,
David Howells <dhowells@redhat.com>,
netdev@vger.kernel.org, Dave Chinner <david@fromorbit.com>,
Jens Axboe <axboe@kernel.dk>,
linux-fsdevel@kvack.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
linux-fsdevel@vger.kernel.org
Subject: Re: [RFC PATCH 1/4] splice: Fix corruption of spliced data after splice() returns
Date: Wed, 19 Jul 2023 13:16:07 -0700 [thread overview]
Message-ID: <CAHk-=wiq95bWiWLyz96ombPfpy=PNrc2KKyzJ2d+WMrxi6=OVA@mail.gmail.com> (raw)
In-Reply-To: <ZLg9HbhOVnLk1ogA@casper.infradead.org>
On Wed, 19 Jul 2023 at 12:44, Matthew Wilcox <willy@infradead.org> wrote:
>
> So what's the API that provides the semantics of _copying_?
It's called "read()" and "write()".
Seriously.
The *ONLY* reason for splice() existing is for zero-copy. If you don't
want zero-copy (aka "copy by reference"), don't use splice.
Stop arguing against it. If you don't want zero-copy, you use read()
and write(). It really is that simple.
And no, we don't start some kind of crazy "versioned zero-copy with
COW". That's a fundamental mistake. It's a mistake that has been done
- several times - and made perhaps most famous by Hurd, that made that
a big thing.
And yes, this has been documented *forever*. It may not have been
documented on the first line, because IT WAS SO OBVIOUS. The whole
reason splice() is fast is because it avoids the actual copy, and does
a copy-by-reference.
That's still a copy. But a copy-by-reference is a special thing. If
you don't know what copy-by-reference is, or don't want it, don't use
splice().
I don't know how many different ways I can say the same thing.
IF YOU DON'T WANT ZERO-COPY, DON'T USE SPLICE.
IF YOU DON'T UNDERSTAND THE DIFFERENCE BETWEEN COPY-BY-VALUE AND
COPY-BY-REFERENCE, DON'T USE SPLICE.
IF YOU DON'T UNDERSTAND THE *POINT* OF SPLICE, DON'T USE SPLICE.
It's kind of a bit like pointers in C: if you don't understand
pointers but use them anyway, you're going to have a hard time. That's
not the fault of the pointers. Pointers are very very powerful. But if
you are used to languages that only do copy-by-value, you are going to
think they are bad things.
Linus
next prev parent reply other threads:[~2023-07-19 20:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-29 15:54 [RFC PATCH 0/4] splice: Fix corruption in data spliced to pipe David Howells
2023-06-29 15:54 ` [RFC PATCH 1/4] splice: Fix corruption of spliced data after splice() returns David Howells
2023-07-19 10:17 ` Miklos Szeredi
2023-07-19 17:59 ` Matt Whitlock
2023-07-19 19:35 ` Miklos Szeredi
2023-07-19 19:44 ` Matthew Wilcox
2023-07-19 19:56 ` Miklos Szeredi
2023-07-19 20:04 ` Matthew Wilcox
2023-07-19 20:16 ` Linus Torvalds [this message]
2023-07-19 21:02 ` Matt Whitlock
2023-07-19 23:20 ` Linus Torvalds
2023-07-19 23:41 ` Matt Whitlock
2023-07-20 0:00 ` Linus Torvalds
2023-07-19 23:48 ` Linus Torvalds
2023-07-24 9:44 ` David Howells
2023-07-24 13:55 ` Miklos Szeredi
2023-07-24 16:15 ` David Howells
2023-06-29 15:54 ` [RFC PATCH 2/4] splice: Make vmsplice() steal or copy David Howells
2023-06-30 13:44 ` Simon Horman
2023-06-30 15:29 ` David Howells
2023-06-30 17:32 ` Simon Horman
2023-06-29 15:54 ` [RFC PATCH 3/4] splice: Remove some now-unused bits David Howells
2023-06-29 15:54 ` [RFC PATCH 4/4] splice: Record some statistics David Howells
2023-06-29 17:56 ` [RFC PATCH 0/4] splice: Fix corruption in data spliced to pipe Linus Torvalds
2023-06-29 18:05 ` Matt Whitlock
2023-06-29 18:19 ` Linus Torvalds
2023-06-29 18:34 ` Matthew Wilcox
2023-06-29 18:53 ` Linus Torvalds
2023-06-30 16:50 ` David Howells
2023-06-29 18:42 ` Linus Torvalds
2023-06-29 18:16 ` Matt Whitlock
2023-06-30 0:01 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHk-=wiq95bWiWLyz96ombPfpy=PNrc2KKyzJ2d+WMrxi6=OVA@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=david@fromorbit.com \
--cc=dhowells@redhat.com \
--cc=hch@lst.de \
--cc=kernel@mattwhitlock.name \
--cc=linux-fsdevel@kvack.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=miklos@szeredi.hu \
--cc=netdev@vger.kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox