From: Dave Chinner <david@fromorbit.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, Jan Kara <jack@suse.com>,
linux-ext4@vger.kernel.org,
Dan Williams <dan.j.williams@intel.com>,
linux-nvdimm@lists.01.org,
Matthew Wilcox <matthew.r.wilcox@intel.com>,
Andreas Dilger <andreas.dilger@intel.com>
Subject: Re: [PATCH 2/2] ext2: Add locking for DAX faults
Date: Mon, 12 Oct 2015 10:14:43 +1100 [thread overview]
Message-ID: <20151011231443.GY27164@dastard> (raw)
In-Reply-To: <1444428128-12200-3-git-send-email-ross.zwisler@linux.intel.com>
[Nit: please send all patches of the series to the same list of
recipients. Otherwise people with list based filters end up with the
series spread across different mailboxes and people not subscribed
to all lists don't get the full series and so are lacking in context
for proper review. ]
On Fri, Oct 09, 2015 at 04:02:08PM -0600, Ross Zwisler wrote:
> Add locking to ensure that DAX faults are isolated from ext2 operations
> that modify the data blocks allocation for an inode. This is intended to
> be analogous to the work being done in XFS by Dave Chinner:
>
> http://www.spinics.net/lists/linux-fsdevel/msg90260.html
>
> Compared with XFS the ext2 case is greatly simplified by the fact that ext2
> already allocates and zeros new blocks before they are returned as part of
> ext2_get_block(), so DAX doesn't need to worry about getting unmapped or
> unwritten buffer heads.
>
> This means that the only work we need to do in ext2 is to isolate the DAX
> faults from inode block allocation changes. I believe this just means that
> we need to isolate the DAX faults from truncate operations.
Why limit this just to DAX page faults?
> The newly introduced dax_sem is intended to replicate the protection
> offered by i_mmaplock in XFS. In addition to truncate the i_mmaplock also
> protects XFS operations like hole punching, fallocate down, extent
> manipulation IOCTLS like xfs_ioc_space() and extent swapping. Truncate is
> the only one of these operations supported by ext2.
>
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> ---
> fs/ext2/ext2.h | 1 +
> fs/ext2/file.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++----
> fs/ext2/inode.c | 9 +++++++++
> fs/ext2/super.c | 1 +
> 4 files changed, 58 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ext2/ext2.h b/fs/ext2/ext2.h
> index 8d15feb..ec3cd02 100644
> --- a/fs/ext2/ext2.h
> +++ b/fs/ext2/ext2.h
> @@ -684,6 +684,7 @@ struct ext2_inode_info {
> struct rw_semaphore xattr_sem;
> #endif
> rwlock_t i_meta_lock;
> + struct rw_semaphore dax_sem;
>
> /*
> * truncate_mutex is for serialising ext2_truncate() against
> diff --git a/fs/ext2/file.c b/fs/ext2/file.c
> index 1982c3f..389c5d5 100644
> --- a/fs/ext2/file.c
> +++ b/fs/ext2/file.c
> @@ -27,27 +27,70 @@
> #include "acl.h"
>
> #ifdef CONFIG_FS_DAX
> +/*
> + * The lock ordering for ext2 DAX fault paths is:
> + *
> + * mmap_sem (MM)
> + * ext2_inode_info->dax_sem
> + * sb_start_pagefault (vfs, freeze - taken in DAX)
> + * address_space->i_mmap_rwsem or page_lock (mutually exclusive in DAX)
> + * ext2_inode_info->truncate_mutex
This is a different lock order to XFS - it puts the i_mmaplock
inside sb_start_pagefault(), not outside it. This ordering means the
timestamp updates during the page fault are also under
ext2_inode_info->dax_sem...
Other than that, I can't really comment on the rest of the changes.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2015-10-11 23:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-09 22:02 [PATCH 0/2] Add updated DAX locking to ext2 Ross Zwisler
2015-10-09 22:02 ` [PATCH 2/2] ext2: Add locking for DAX faults Ross Zwisler
2015-10-09 22:18 ` Dan Williams
2015-10-09 22:38 ` Ross Zwisler
2015-10-11 23:14 ` Dave Chinner [this message]
2015-10-12 17:21 ` Ross Zwisler
2015-10-12 23:02 ` Dave Chinner
2015-10-12 21:41 ` Ross Zwisler
2015-10-12 23:24 ` Dave Chinner
2015-10-12 23:35 ` Eric Curtin
2015-10-13 22:15 ` Ross Zwisler
2015-10-13 15:02 ` Ross Zwisler
2015-10-13 8:07 ` Jan Kara
2015-10-13 17:33 ` Ross Zwisler
2015-10-13 17:47 ` 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=20151011231443.GY27164@dastard \
--to=david@fromorbit.com \
--cc=andreas.dilger@intel.com \
--cc=dan.j.williams@intel.com \
--cc=jack@suse.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.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