All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] splice: fix premature end of input detection
@ 2020-10-05 12:13 Tetsuo Handa
  2020-10-05 18:26 ` Linus Torvalds
  0 siblings, 1 reply; 3+ messages in thread
From: Tetsuo Handa @ 2020-10-05 12:13 UTC (permalink / raw)
  To: David Howells, Al Viro, Linus Torvalds; +Cc: linux-fsdevel, Tetsuo Handa

splice() from pipe should return 0 when there is no pipe writer. However,
since commit a194dfe6e6f6f720 ("pipe: Rearrange sequence in pipe_write()
to preallocate slot") started inserting empty pages, splice() from pipe
also returns 0 when all ready buffers are empty pages.

----------
#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
        const int fd = open("/tmp/testfile", O_WRONLY | O_CREAT, 0600);
        int pipe_fd[2] = { -1, -1 };
        pipe(pipe_fd);
        write(pipe_fd[1], NULL, 4096);
	/* This splice() should wait unless interrupted. */
        return !splice(pipe_fd[0], NULL, fd, NULL, 65536, 0);
}
----------

Since such behavior might confuse splice() users, let's fix it by waiting
for non-empty pages inside splice_from_pipe_next().

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fixes: a194dfe6e6f6f720 ("pipe: Rearrange sequence in pipe_write() to preallocate slot")
Cc: stable@vger.kernel.org # 5.5+
---
 fs/splice.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/fs/splice.c b/fs/splice.c
index c3d00dfc7344..b58c7ebf6805 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -538,6 +538,8 @@ static int splice_from_pipe_feed(struct pipe_inode_info *pipe, struct splice_des
  */
 static int splice_from_pipe_next(struct pipe_inode_info *pipe, struct splice_desc *sd)
 {
+	unsigned int head, tail, mask;
+
 	/*
 	 * Check for signal early to make process killable when there are
 	 * always buffers available
@@ -545,6 +547,7 @@ static int splice_from_pipe_next(struct pipe_inode_info *pipe, struct splice_des
 	if (signal_pending(current))
 		return -ERESTARTSYS;
 
+ refill:
 	while (pipe_empty(pipe->head, pipe->tail)) {
 		if (!pipe->writers)
 			return 0;
@@ -566,7 +569,21 @@ static int splice_from_pipe_next(struct pipe_inode_info *pipe, struct splice_des
 		pipe_wait_readable(pipe);
 	}
 
-	return 1;
+	head = pipe->head;
+	tail = pipe->tail;
+	mask = pipe->ring_size - 1;
+
+	/* dismiss the empty buffers */
+	while (!pipe_empty(head, tail)) {
+		struct pipe_buffer *buf = &pipe->bufs[tail & mask];
+
+		if (likely(buf->len))
+			return 1;
+		pipe_buf_release(pipe, buf);
+		pipe->tail = ++tail;
+	}
+	/* wait again if all buffers were empty */
+	goto refill;
 }
 
 /**
-- 
2.18.4


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] splice: fix premature end of input detection
  2020-10-05 12:13 [PATCH v2] splice: fix premature end of input detection Tetsuo Handa
@ 2020-10-05 18:26 ` Linus Torvalds
  2020-10-05 23:47   ` Tetsuo Handa
  0 siblings, 1 reply; 3+ messages in thread
From: Linus Torvalds @ 2020-10-05 18:26 UTC (permalink / raw)
  To: Tetsuo Handa; +Cc: David Howells, Al Viro, linux-fsdevel

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

On Mon, Oct 5, 2020 at 5:14 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> splice() from pipe should return 0 when there is no pipe writer. However,
> since commit a194dfe6e6f6f720 ("pipe: Rearrange sequence in pipe_write()
> to preallocate slot") started inserting empty pages, splice() from pipe
> also returns 0 when all ready buffers are empty pages.

Well... Only if you had writers that intentionally did that whole "no
valid data write" thing.

Which could be seen as a feature.

That said, if this actually broke some code, then we need to fix it -
but I really hate how you have that whole !pipe_empty() loop around
the empty buffers.

That case is very unlikely, and you have a loop with !pipe_empty()
*anyway* with the whole "goto refill". So the loop is completely
pointless.

Also, what if we have a packet pipe? Do we perhaps want to return at
packet boundaries? I don't think splice() has cared, so probably not,
but it's worth perhaps thinking about.

Anyway, I'd be a lot happier with the patch being structured something
like this instead.. UNTESTED

                Linus

[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 1249 bytes --]

 fs/splice.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/fs/splice.c b/fs/splice.c
index c3d00dfc7344..ce75aec52274 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -526,6 +526,22 @@ static int splice_from_pipe_feed(struct pipe_inode_info *pipe, struct splice_des
 	return 1;
 }
 
+/* We know we have a pipe buffer, but maybe it's empty? */
+static inline bool eat_empty_buffer(struct pipe_inode_info *pipe)
+{
+	unsigned int tail = pipe->tail;
+	unsigned int mask = pipe->ring_size - 1;
+	struct pipe_buffer *buf = &pipe->bufs[tail & mask];
+
+	if (unlikely(!buf->len)) {
+		pipe_buf_release(pipe, buf);
+		pipe->tail = tail+1;
+		return true;
+	}
+
+	return false;
+}
+
 /**
  * splice_from_pipe_next - wait for some data to splice from
  * @pipe:	pipe to splice from
@@ -545,6 +561,7 @@ static int splice_from_pipe_next(struct pipe_inode_info *pipe, struct splice_des
 	if (signal_pending(current))
 		return -ERESTARTSYS;
 
+repeat:
 	while (pipe_empty(pipe->head, pipe->tail)) {
 		if (!pipe->writers)
 			return 0;
@@ -566,6 +583,9 @@ static int splice_from_pipe_next(struct pipe_inode_info *pipe, struct splice_des
 		pipe_wait_readable(pipe);
 	}
 
+	if (eat_empty_buffer(pipe))
+		goto repeat;
+
 	return 1;
 }
 

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] splice: fix premature end of input detection
  2020-10-05 18:26 ` Linus Torvalds
@ 2020-10-05 23:47   ` Tetsuo Handa
  0 siblings, 0 replies; 3+ messages in thread
From: Tetsuo Handa @ 2020-10-05 23:47 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: David Howells, Al Viro, linux-fsdevel

On 2020/10/06 3:26, Linus Torvalds wrote:
> On Mon, Oct 5, 2020 at 5:14 AM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>
>> splice() from pipe should return 0 when there is no pipe writer. However,
>> since commit a194dfe6e6f6f720 ("pipe: Rearrange sequence in pipe_write()
>> to preallocate slot") started inserting empty pages, splice() from pipe
>> also returns 0 when all ready buffers are empty pages.
> 
> Well... Only if you had writers that intentionally did that whole "no
> valid data write" thing.
> 
> Which could be seen as a feature.

pipe_read() is aware of such writers.

  /*
   * We only get here if we didn't actually read anything.
   *
   * However, we could have seen (and removed) a zero-sized
   * pipe buffer, and might have made space in the buffers
   * that way.
   *
   * You can't make zero-sized pipe buffers by doing an empty
   * write (not even in packet mode), but they can happen if
   * the writer gets an EFAULT when trying to fill a buffer
   * that already got allocated and inserted in the buffer
   * array.
   *
   * So we still need to wake up any pending writers in the
   * _very_ unlikely case that the pipe was full, but we got
   * no data.
   */

We also need to care about handle_userfault()
( https://lkml.kernel.org/r/29dd8637-5e44-db4a-9aea-305b079941fb@i-love.sakura.ne.jp )
which we might change it to return an error when pagefault from
pipe_write() takes too long.

> 
> That said, if this actually broke some code, then we need to fix it -
> but I really hate how you have that whole !pipe_empty() loop around
> the empty buffers.
> 
> That case is very unlikely, and you have a loop with !pipe_empty()
> *anyway* with the whole "goto refill". So the loop is completely
> pointless.

This loop just removes all leading empty pages at once.
"goto refill" is a result of all pages were empty.

> 
> Also, what if we have a packet pipe? Do we perhaps want to return at
> packet boundaries? I don't think splice() has cared, so probably not,
> but it's worth perhaps thinking about.

Since manpage says that "Zero-length packets are not supported.", I think that
skipping leading empty pages (either my version or your version) will not break
packet boundaries.

This check is there to avoid returning 0 when all available buffers are empty.
This check should remain no-op if some buffer is not empty.

> 
> Anyway, I'd be a lot happier with the patch being structured something
> like this instead.. UNTESTED

I'm OK with your version.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-10-05 23:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-05 12:13 [PATCH v2] splice: fix premature end of input detection Tetsuo Handa
2020-10-05 18:26 ` Linus Torvalds
2020-10-05 23:47   ` Tetsuo Handa

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.