From: David Howells <dhowells@redhat.com>
To: netdev@vger.kernel.org
Cc: David Howells <dhowells@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Dave Chinner <david@fromorbit.com>,
Matt Whitlock <kernel@mattwhitlock.name>,
Linus Torvalds <torvalds@linux-foundation.org>,
Jens Axboe <axboe@kernel.dk>,
linux-fsdevel@kvack.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: [RFC PATCH 0/4] splice: Fix corruption in data spliced to pipe
Date: Thu, 29 Jun 2023 16:54:29 +0100 [thread overview]
Message-ID: <20230629155433.4170837-1-dhowells@redhat.com> (raw)
Due to the way splice() and vmsplice() currently splice active pages from
the pagecache or process VM into the intermediary pipe, changes to the data
in those pages can occur whilst they're held in the pipe by such as
write(), writing through a shared-writable mmap or using fallocate() to
mangle the file[1] change the data.
Matt Whitlock, Matthew Wilcox and Dave Chinner are of the opinion that data
in the pipe must not be seen to change and that if it does, this is a bug.
Apart from in one specific instance (vmsplice() with SPLICE_F_GIFT), the
manual pages agree with them. I'm more inclined to adjust the
documentation since the behaviour we have has been that way since 2005, I
think.
These patches attempt to fix this by stealing a page if possible and
copying the data if not before splice() or vmsplice() adds it to the pipe.
Whilst this does allow the code to be somewhat simplified, it also results
in a loss of performance: stolen pages have to be reloaded in accessed
again; more data has to be copied.
Ideally, this should result in all pages in the pipe belonging solely to
the pipe and so they can be removed from the pipe and spliced into
pagecaches or process VM immediately with no further checking required.
Note that this conversion is incomplete. It does not simplify fuse and
virtio_console and it does not clean up the splicing into pipes from
relayfs, watch_queue and sockets.
There's also a bug in the vmsplice() page stealing. It mostly works but
after splicing a bunch of pages, it will oops somewhere in the interval
tree's macros.
I've pushed the patches here also:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=splice-fix-corruption
David
Link: https://lore.kernel.org/r/ec804f26-fa76-4fbe-9b1c-8fbbd829b735@mattwhitlock.name/ [1]
David Howells (4):
splice: Fix corruption of spliced data after splice() returns
splice: Make vmsplice() steal or copy
splice: Remove some now-unused bits
splice: Record some statistics
fs/fuse/dev.c | 37 -----
fs/pipe.c | 12 --
fs/splice.c | 304 ++++++++++++++++++--------------------
include/linux/pipe_fs_i.h | 14 --
include/linux/splice.h | 4 +-
mm/filemap.c | 98 +++++++++++-
mm/internal.h | 4 +-
mm/shmem.c | 8 +-
8 files changed, 245 insertions(+), 236 deletions(-)
next reply other threads:[~2023-06-29 15:55 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-29 15:54 David Howells [this message]
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
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=20230629155433.4170837-1-dhowells@redhat.com \
--to=dhowells@redhat.com \
--cc=axboe@kernel.dk \
--cc=david@fromorbit.com \
--cc=kernel@mattwhitlock.name \
--cc=linux-fsdevel@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.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