From: Theodore Ts'o <tytso@mit.edu>
To: Jan Kara <jack@suse.com>
Cc: linux-ext4@vger.kernel.org,
Dan Williams <dan.j.williams@intel.com>,
ross.zwisler@linux.intel.com, willy@linux.intel.com
Subject: Re: [PATCH 1/9] ext4: Fix races between page faults and hole punching
Date: Fri, 23 Oct 2015 21:21:35 -0400 [thread overview]
Message-ID: <20151024012135.GG7917@thunk.org> (raw)
In-Reply-To: <1445501761-14528-2-git-send-email-jack@suse.com>
On Thu, Oct 22, 2015 at 10:15:53AM +0200, Jan Kara wrote:
> Currently, page faults and hole punching are completely unsynchronized.
> This can result in page fault faulting in a page into a range that we
> are punching after truncate_pagecache_range() has been called and thus
> we can end up with a page mapped to disk blocks that will be shortly
> freed. Filesystem corruption will shortly follow. Note that the same
> race is avoided for truncate by checking page fault offset against
> i_size but there isn't similar mechanism available for punching holes.
>
> Fix the problem by creating new rw semaphore i_mmap_sem in inode and
> grab it for writing over truncate, hole punching, and other functions
> removing blocks from extent tree and for read over page faults. We
> cannot easily use i_data_sem for this since that ranks below transaction
> start and we need something ranking above it so that it can be held over
> the whole truncate / hole punching operation. Also remove various
> workarounds we had in the code to reduce race window when page fault
> could have created pages with stale mapping information.
>
> Signed-off-by: Jan Kara <jack@suse.com>
This patch is causing ext4/001 to fail even using the standard 4k
non-DAX test configuration. You had mentioned that extent zeroing was
getting suppressed for DAX file systems, but it looks like it's
getting suppressed even in the non-DAX configuration:
% kvm-xfstests -c 4k ext4/001
...
ext4/001 [21:11:29][ 7.796142] run fstests ext4/001 at 2015-10-23 21:11:29
[21:11:32] - output mismatch (see /results/results-4k/ext4/001.out.bad)
--- tests/ext4/001.out 2015-10-18 23:46:49.000000000 -0400
+++ /results/results-4k/ext4/001.out.bad 2015-10-23 21:11:32.104276540 -0400
@@ -131,14 +131,10 @@
2: [32..39]: hole
daa100df6e6711906b61c9ab5aa16032
11. data -> hole -> data
-0: [0..7]: data
-1: [8..31]: unwritten
-2: [32..39]: data
+0: [0..39]: data
...
(Run 'diff -u tests/ext4/001.out /results/results-4k/ext4/001.out.bad' to see the entire diff)
- Ted
next prev parent reply other threads:[~2015-10-24 10:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-22 8:15 [PATCH 0/9 v2] ext4: Punch hole and DAX fixes Jan Kara
2015-10-22 8:15 ` [PATCH 1/9] ext4: Fix races between page faults and hole punching Jan Kara
2015-10-24 1:21 ` Theodore Ts'o [this message]
2015-10-25 4:58 ` Jan Kara
2015-10-22 8:15 ` [PATCH 2/9] ext4: Move unlocked dio protection from ext4_alloc_file_blocks() Jan Kara
2015-10-22 8:15 ` [PATCH 3/9] ext4: Fix races between buffered IO and collapse / insert range Jan Kara
2015-10-24 1:22 ` Theodore Ts'o
2015-10-24 4:59 ` Theodore Ts'o
2015-10-22 8:15 ` [PATCH 4/9] ext4: Fix races of writeback with punch hole and zero range Jan Kara
2015-10-22 8:15 ` [PATCH 5/9] ext4: Document lock ordering Jan Kara
2015-10-22 8:15 ` [PATCH 6/9] ext4: Get rid of EXT4_GET_BLOCKS_NO_LOCK flag Jan Kara
2015-10-22 8:15 ` [PATCH 7/9] ext4: Provide ext4_issue_zeroout() Jan Kara
2015-10-22 8:16 ` [PATCH 8/9] ext4: Implement allocation of pre-zeroed blocks Jan Kara
2015-10-22 8:16 ` [PATCH 9/9] ext4: Use pre-zeroed blocks for DAX page faults Jan Kara
2015-10-25 9:23 ` Theodore Ts'o
2015-10-22 18:09 ` [PATCH 0/9 v2] ext4: Punch hole and DAX fixes Ross Zwisler
2015-10-22 21:14 ` Jan Kara
2015-10-23 3:35 ` Eryu Guan
-- strict thread matches above, loose matches on Subject: below --
2015-11-04 16:18 [PATCH 0/9 v3] " Jan Kara
2015-11-04 16:18 ` [PATCH 1/9] ext4: Fix races between page faults and hole punching Jan Kara
2015-11-10 19:50 [PATCH 0/9 v4] ext4: Punch hole and DAX fixes Jan Kara
2015-11-10 19:50 ` [PATCH 1/9] ext4: Fix races between page faults and hole punching 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=20151024012135.GG7917@thunk.org \
--to=tytso@mit.edu \
--cc=dan.j.williams@intel.com \
--cc=jack@suse.com \
--cc=linux-ext4@vger.kernel.org \
--cc=ross.zwisler@linux.intel.com \
--cc=willy@linux.intel.com \
/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).