From: Jan Kara <jack@suse.com>
To: linux-ext4@vger.kernel.org
Cc: Dan Williams <dan.j.williams@intel.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
Matthew Wilcox <matthew.r.wilcox@intel.com>,
Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.com>
Subject: [PATCH 0/6] ext4: Punch hole and DAX fixes
Date: Wed, 14 Oct 2015 13:30:21 +0200 [thread overview]
Message-ID: <1444822227-29984-1-git-send-email-jack@suse.com> (raw)
Hello,
This series fixes a long standing problem of racing punch hole and page fault
resulting in possible filesystem corruption or stale data exposure. We fix the
problem by using a new inode-private rw_semaphore i_mmap_sem to synchronize
page faults with truncate and punch hole operations.
When having this exclusion, the only remaining problem with DAX implementation
are races between two page faults zeroing out same block concurrently (where
the data written after the first fault finishes are possibly overwritten by
the second fault still doing zeroing). That is dealt with by patches 5 and 6
in this series where we implement block zeroing directly in ext4_map_blocks().
The patches survived xfstests run both in dax and non-dax mode.
Honza
next reply other threads:[~2015-10-14 11:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-14 11:30 Jan Kara [this message]
2015-10-14 11:30 ` [PATCH 1/6] ext4: Fix races between page faults and hole punching Jan Kara
2015-10-15 3:00 ` Ross Zwisler
2015-10-15 9:14 ` Jan Kara
2015-10-15 20:22 ` Dave Chinner
2015-10-14 11:30 ` [PATCH 2/6] ext4: Document lock ordering Jan Kara
2015-10-14 11:30 ` [PATCH 3/6] ext4: Get rid of EXT4_GET_BLOCKS_NO_LOCK flag Jan Kara
2015-10-14 11:30 ` [PATCH 4/6] ext4: Provide ext4_issue_zeroout() Jan Kara
2015-10-14 13:18 ` kbuild test robot
2015-10-14 11:30 ` [PATCH 5/6] ext4: Implement allocation of pre-zeroed blocks Jan Kara
2015-10-14 11:30 ` [PATCH 6/6] ext4: Use pre-zeroed blocks for DAX page faults Jan Kara
2015-10-14 18:06 ` [PATCH 0/6] ext4: Punch hole and DAX fixes Ross Zwisler
2015-10-14 21:07 ` Ross Zwisler
2015-10-15 9:13 ` 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=1444822227-29984-1-git-send-email-jack@suse.com \
--to=jack@suse.com \
--cc=dan.j.williams@intel.com \
--cc=david@fromorbit.com \
--cc=linux-ext4@vger.kernel.org \
--cc=matthew.r.wilcox@intel.com \
--cc=ross.zwisler@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).