From: David Howells <dhowells@redhat.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: dhowells@redhat.com, Dave Chinner <david@fromorbit.com>,
Matt Whitlock <kernel@mattwhitlock.name>,
linux-fsdevel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
Jens Axboe <axboe@kernel.dk>, Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [Reproducer] Corruption, possible race between splice and FALLOC_FL_PUNCH_HOLE
Date: Wed, 28 Jun 2023 07:30:50 +0100 [thread overview]
Message-ID: <3299543.1687933850@warthog.procyon.org.uk> (raw)
In-Reply-To: <ZJq6nJBoX1m6Po9+@casper.infradead.org>
Matthew Wilcox <willy@infradead.org> wrote:
> > > Expected behavior:
> > > Punching holes in a file after splicing pages out of that file into a pipe
> > > should not corrupt the spliced-out pages in the pipe buffer.
I think this bit is the key. Why would this be the expected behaviour? As
you say, splice is allowed to stuff parts of the pagecache into a pipe and
these may get transferred, say, to a network card at the end to transmit
directly from. It's a form of direct I/O. If someone has the pages mmapped,
they can change the data that will be transmitted; if someone does a write(),
they can change that data too. The point of splice is to avoid the copy - but
it comes with a tradeoff.
David
next prev parent reply other threads:[~2023-06-28 8:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-27 1:12 [Reproducer] Corruption, possible race between splice and FALLOC_FL_PUNCH_HOLE Matt Whitlock
2023-06-27 5:47 ` Dave Chinner
2023-06-27 6:20 ` Dave Chinner
2023-06-27 10:31 ` Matthew Wilcox
2023-06-27 18:38 ` Matt Whitlock
2023-06-27 21:49 ` Dave Chinner
2023-06-28 6:30 ` David Howells [this message]
2023-06-28 8:15 ` Dave Chinner
2023-06-28 9:33 ` David Howells
2023-06-28 12:51 ` Matthew Wilcox
2023-06-28 14:19 ` David Howells
2023-06-28 22:41 ` Dave Chinner
2023-06-28 17:35 ` Matt Whitlock
2023-06-28 18:27 ` David Howells
2023-06-28 22:17 ` Dave Chinner
2023-06-27 18:14 ` Matt Whitlock
2023-06-27 21:51 ` Dave Chinner
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=3299543.1687933850@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=axboe@kernel.dk \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=kernel@mattwhitlock.name \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--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 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.