From: Theodore Ts'o <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: Maxim Patlasov <MPatlasov@parallels.com>,
adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ext4: avoid exposure of stale data in ext4_punch_hole() -v2
Date: Thu, 20 Feb 2014 19:21:07 -0500 [thread overview]
Message-ID: <20140221002107.GB7232@thunk.org> (raw)
In-Reply-To: <20130927160517.GA5777@quack.suse.cz>
On Fri, Sep 27, 2013 at 06:05:17PM +0200, Jan Kara wrote:
> On Fri 27-09-13 19:54:03, Maxim Patlasov wrote:
> > While handling punch-hole fallocate, it's useless to truncate page cache
> > before removing the range from extent tree (or block map in indirect case)
> > because page cache can be re-populated (by read-ahead or read(2) or mmap-ed
> > read) immediately after truncating page cache, but before updating extent
> > tree (or block map). In that case the user will see stale data even after
> > fallocate is completed.
> >
> > Changed in v2 (Thanks to Jan Kara):
> > - Until the problem of data corruption resulting from pages backed by
> > already freed blocks is fully resolved, the simple thing we can do now
> > is to add another truncation of pagecache after punch hole is done.
> The patch looks good. You can add:
> Reviewed-by: Jan Kara <jack@suse.cz>
I was going through old patches, and it looks like this one got
dropped. My apologies.
As far as I can tell, the underlying problem in the VFS/MM layer
hasn't been solved yet (Jan, can you confirm?), so I've queued this
patch for the next merge window.
- Ted
next prev parent reply other threads:[~2014-02-21 0:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-26 17:32 [PATCH] ext4: avoid exposure of stale data in ext4_punch_hole() Maxim Patlasov
2013-09-26 17:32 ` Maxim Patlasov
2013-09-26 18:53 ` Jan Kara
2013-09-27 13:05 ` Maxim Patlasov
2013-09-27 14:43 ` Jan Kara
2013-09-27 15:16 ` Maxim Patlasov
2013-09-27 15:54 ` [PATCH] ext4: avoid exposure of stale data in ext4_punch_hole() -v2 Maxim Patlasov
2013-09-27 16:05 ` Jan Kara
2014-02-21 0:21 ` Theodore Ts'o [this message]
2014-02-21 9:45 ` Jan Kara
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=20140221002107.GB7232@thunk.org \
--to=tytso@mit.edu \
--cc=MPatlasov@parallels.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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.