From: Linus Torvalds <torvalds@linux-foundation.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: jens.axboe@oracle.com, Max Kellermann <max@duempel.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 0/3] make splice more generic
Date: Thu, 7 May 2009 08:55:03 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0905070845590.4983@localhost.localdomain> (raw)
In-Reply-To: <20090507133734.450612199@szeredi.hu>
On Thu, 7 May 2009, Miklos Szeredi wrote:
>
> One more generalization would be to allow splice to work on two
> non-pipes, using an internal intermediate pipe, a-la do_splice_direct().
You can't do that without some painful issues.
Or rather, you can only do it trivially for the one case where we
_already_ do that, namely "sendfile()". That's exactly what sendfile() is
now.
What is so painful about it in general?
Reading from a source may _destroy_ that data, and you may not be able to
push it back to the source. And what happens if the destination cannot
take it?
Now, we could do a totally blocking version that simply refuses to return
until the destination has taken all the splice data, and maybe it would be
worth it as a simplified interface. But it does sound like a really ripe
place for deadlocks etc (set up some trivial circular thing of everybody
trying to pipe to each other, and all of them getting blocked on the
receiver, and now they are unkillable).
Now, the reason it works for sendfile() is that when the source is known
to be in the page cache, then if the receiver doesn't take the data, we
know we can just drop it. But what if the source is some character device
driver? We can't just drop the data on a signal.
So the reason splice does that pipe buffer is that the pipe itself then
acts as a long-term buffer _across_ the kernel returning to user space,
and thus allows the whole process to be interruptible.
That said, maybe we could allow it in a few more cases. Or maybe people
think the simplification in user interfaces is worth making the IO be
non-interruptible (but still killable, for example, at which point the
buffered data really is dropped - but that's not different from having
the buffers in user space, so at that point it's ok).
So I'm certainly willing to be convinced that it's a good idea after all,
it just worries me, and I wanted to point out the painful issues that
caused me to not allow it in general.
Linus
next prev parent reply other threads:[~2009-05-07 15:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-07 13:37 [patch 0/3] make splice more generic Miklos Szeredi
2009-05-07 13:37 ` [patch 1/3] splice: implement pipe to pipe splicing Miklos Szeredi
2009-05-07 13:37 ` [patch 2/3] splice: implement default splice_read method Miklos Szeredi
2009-05-13 5:35 ` Andrew Morton
2009-05-13 6:37 ` Jens Axboe
2009-05-13 9:01 ` Miklos Szeredi
2009-05-14 17:29 ` Jens Axboe
2009-05-14 17:54 ` Miklos Szeredi
2009-05-14 18:00 ` Jens Axboe
2009-05-18 12:36 ` Miklos Szeredi
2009-05-19 9:38 ` Jens Axboe
2009-05-07 13:37 ` [patch 3/3] splice: implement default splice_write method Miklos Szeredi
2009-05-07 15:55 ` Linus Torvalds [this message]
2009-05-11 15:17 ` [patch 0/3] make splice more generic Miklos Szeredi
2009-05-09 11:36 ` Max Kellermann
2009-05-11 12:12 ` Jens Axboe
2009-05-11 15:22 ` Miklos Szeredi
2009-05-14 20:27 ` Jamie Lokier
2009-05-15 7:32 ` Jens Axboe
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=alpine.LFD.2.01.0905070845590.4983@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=jens.axboe@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=max@duempel.org \
--cc=miklos@szeredi.hu \
/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;
as well as URLs for NNTP newsgroup(s).