diff mbox

[2/2] ext2: Add locking for DAX faults

Message ID 1444428128-12200-3-git-send-email-ross.zwisler@linux.intel.com
State Accepted, archived
Headers show

Commit Message

Ross Zwisler Oct. 9, 2015, 10:02 p.m. UTC
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.

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(-)

Comments

Dan Williams Oct. 9, 2015, 10:18 p.m. UTC | #1
On Fri, Oct 9, 2015 at 3:02 PM, Ross Zwisler
<ross.zwisler@linux.intel.com> 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.
>
> 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>
[..]

...not a review of the ext2 changes.

> diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
> index c60a248..2b974fc 100644
> --- a/fs/ext2/inode.c
> +++ b/fs/ext2/inode.c
> @@ -1085,6 +1085,7 @@ static void ext2_free_branches(struct inode *inode, __le32 *p, __le32 *q, int de
>                 ext2_free_data(inode, p, q);
>  }
>
> +/* dax_sem must be held when calling this function */
>  static void __ext2_truncate_blocks(struct inode *inode, loff_t offset)
>  {

How about  a "WARN_ON(!rwsem_is_locked(&ei->dax_sem));" to backstop
this assumption?
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ross Zwisler Oct. 9, 2015, 10:38 p.m. UTC | #2
On Fri, Oct 09, 2015 at 03:18:11PM -0700, Dan Williams wrote:
> On Fri, Oct 9, 2015 at 3:02 PM, Ross Zwisler
> <ross.zwisler@linux.intel.com> 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.
> >
> > 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>
> [..]
> 
> ...not a review of the ext2 changes.
> 
> > diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
> > index c60a248..2b974fc 100644
> > --- a/fs/ext2/inode.c
> > +++ b/fs/ext2/inode.c
> > @@ -1085,6 +1085,7 @@ static void ext2_free_branches(struct inode *inode, __le32 *p, __le32 *q, int de
> >                 ext2_free_data(inode, p, q);
> >  }
> >
> > +/* dax_sem must be held when calling this function */
> >  static void __ext2_truncate_blocks(struct inode *inode, loff_t offset)
> >  {
> 
> How about  a "WARN_ON(!rwsem_is_locked(&ei->dax_sem));" to backstop
> this assumption?

Yep, sounds like a good idea.  Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dave Chinner Oct. 11, 2015, 11:14 p.m. UTC | #3
[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.
Ross Zwisler Oct. 12, 2015, 5:21 p.m. UTC | #4
On Mon, Oct 12, 2015 at 10:14:43AM +1100, Dave Chinner wrote:
> [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. ]

Okay, will do.

> On Fri, Oct 09, 2015 at 04:02:08PM -0600, Ross Zwisler wrote:
<>
> > +/*
> > + * 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...

Yep - I was trying not not open code dax_fault() yet again, but it looks like
both XFS and ext4 both open-code dax_fault() and call __dax_fault() directly.

I assume that when we get an analogous lock to i_mmaplock in the ext4 fault
path we'll end up with the same locking order that is found in XFS.

I'll do the same for v2 of this patch and I'll kill the then-unused
dax_fault().
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ross Zwisler Oct. 12, 2015, 9:41 p.m. UTC | #5
On Mon, Oct 12, 2015 at 10:14:43AM +1100, Dave Chinner wrote:
> 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?

Yep, I see that XFS uses the same locking to protect both DAX and non-DAX
faults.  I'll add this protection to non-DAX ext2 faults as well.

One quick question - it looks like that dax_pmd_fault() only grabs the
pagefault lock and updates the file_update_time() if the FAULT_WRITE_FLAG is
set. In xfs_filemap_pfn_mkwrite(), though, these two steps are taken for read
faults as well.  Is this intentional?
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dave Chinner Oct. 12, 2015, 11:02 p.m. UTC | #6
On Mon, Oct 12, 2015 at 11:21:56AM -0600, Ross Zwisler wrote:
> On Mon, Oct 12, 2015 at 10:14:43AM +1100, Dave Chinner wrote:
> > On Fri, Oct 09, 2015 at 04:02:08PM -0600, Ross Zwisler wrote:
> <>
> > > +/*
> > > + * 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...
> 
> Yep - I was trying not not open code dax_fault() yet again, but it looks like
> both XFS and ext4 both open-code dax_fault() and call __dax_fault() directly.
> 
> I assume that when we get an analogous lock to i_mmaplock in the ext4 fault
> path we'll end up with the same locking order that is found in XFS.
> 
> I'll do the same for v2 of this patch and I'll kill the then-unused
> dax_fault().

Great!

I'd suggest that you also then rename __dax_fault() to dax_fault()
in that case, and also document the requirements for callers in
terms of sb_start_pagefault() and timestamp updates...

Cheers,

Dave.
Dave Chinner Oct. 12, 2015, 11:24 p.m. UTC | #7
On Mon, Oct 12, 2015 at 03:41:35PM -0600, Ross Zwisler wrote:
> On Mon, Oct 12, 2015 at 10:14:43AM +1100, Dave Chinner wrote:
> > 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?
> 
> Yep, I see that XFS uses the same locking to protect both DAX and non-DAX
> faults.  I'll add this protection to non-DAX ext2 faults as well.
> 
> One quick question - it looks like that dax_pmd_fault() only grabs the
> pagefault lock and updates the file_update_time() if the FAULT_WRITE_FLAG is
> set. In xfs_filemap_pfn_mkwrite(), though, these two steps are taken for read
> faults as well.  Is this intentional?

xfs_filemap_pfn_mkwrite() should not be called for read faults.
We've already had to have a fault that maps the page to pfn for us
to get a pfn based fault, and hence that code is correct.

Or are you talking about xfs_filemap_pmd_fault()? In which case, I
refer you to the commit log and it should be obvious that it was
committed without me even looking at it.  I have another patch in my
current series for 4.4 that will fix this.

Cheers,

Dave.
Eric Curtin Oct. 12, 2015, 11:35 p.m. UTC | #8
On 13 October 2015 at 00:24, Dave Chinner <david@fromorbit.com> wrote:
>
> On Mon, Oct 12, 2015 at 03:41:35PM -0600, Ross Zwisler wrote:
> > On Mon, Oct 12, 2015 at 10:14:43AM +1100, Dave Chinner wrote:
> > > 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?
> >
> > Yep, I see that XFS uses the same locking to protect both DAX and non-DAX
> > faults.  I'll add this protection to non-DAX ext2 faults as well.
> >
> > One quick question - it looks like that dax_pmd_fault() only grabs the
> > pagefault lock and updates the file_update_time() if the FAULT_WRITE_FLAG is
> > set. In xfs_filemap_pfn_mkwrite(), though, these two steps are taken for read
> > faults as well.  Is this intentional?
>
> xfs_filemap_pfn_mkwrite() should not be called for read faults.
> We've already had to have a fault that maps the page to pfn for us
> to get a pfn based fault, and hence that code is correct.
>
> Or are you talking about xfs_filemap_pmd_fault()? In which case, I
> refer you to the commit log and it should be obvious that it was
> committed without me even looking at it.  I have another patch in my
> current series for 4.4 that will fix this.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Hi Ross,

For all those int ret declarations. Why not declare and initialize all
on the same line?

Regards,

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Kara Oct. 13, 2015, 8:07 a.m. UTC | #9
On Mon 12-10-15 15:41:35, Ross Zwisler wrote:
> On Mon, Oct 12, 2015 at 10:14:43AM +1100, Dave Chinner wrote:
> > 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?
> 
> Yep, I see that XFS uses the same locking to protect both DAX and non-DAX
> faults.  I'll add this protection to non-DAX ext2 faults as well.

Actually, since ext2 driver doesn't support punch hole, there is no need
for additional locking in non-DAX paths. So we can save some space in inode
and locking for that common case. So I'd prefer if we didn't add
unnecessary locking in those paths and just document that for non-DAX
faults using page lock and i_size check is enough. After all the main
usecase of ext2 driver these days is for people with tiny devices...

								Honza
Ross Zwisler Oct. 13, 2015, 3:02 p.m. UTC | #10
On Tue, Oct 13, 2015 at 10:24:28AM +1100, Dave Chinner wrote:
> On Mon, Oct 12, 2015 at 03:41:35PM -0600, Ross Zwisler wrote:
> > On Mon, Oct 12, 2015 at 10:14:43AM +1100, Dave Chinner wrote:
> > > 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?
> > 
> > Yep, I see that XFS uses the same locking to protect both DAX and non-DAX
> > faults.  I'll add this protection to non-DAX ext2 faults as well.
> > 
> > One quick question - it looks like that dax_pmd_fault() only grabs the
> > pagefault lock and updates the file_update_time() if the FAULT_WRITE_FLAG is
> > set. In xfs_filemap_pfn_mkwrite(), though, these two steps are taken for read
> > faults as well.  Is this intentional?
> 
> xfs_filemap_pfn_mkwrite() should not be called for read faults.
> We've already had to have a fault that maps the page to pfn for us
> to get a pfn based fault, and hence that code is correct.
> 
> Or are you talking about xfs_filemap_pmd_fault()? In which case, I
> refer you to the commit log and it should be obvious that it was
> committed without me even looking at it.  I have another patch in my
> current series for 4.4 that will fix this.

Yep, sorry, I meant xfs_filemap_pmd_fault().  Thanks, I was just making sure the
pattern I'm following in ext2 where I'm only locking the pagefault lock &
updating the file_update_time() on writes was correct.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ross Zwisler Oct. 13, 2015, 5:33 p.m. UTC | #11
On Tue, Oct 13, 2015 at 10:07:12AM +0200, Jan Kara wrote:
> On Mon 12-10-15 15:41:35, Ross Zwisler wrote:
> > On Mon, Oct 12, 2015 at 10:14:43AM +1100, Dave Chinner wrote:
> > > 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?
> > 
> > Yep, I see that XFS uses the same locking to protect both DAX and non-DAX
> > faults.  I'll add this protection to non-DAX ext2 faults as well.
> 
> Actually, since ext2 driver doesn't support punch hole, there is no need
> for additional locking in non-DAX paths. So we can save some space in inode
> and locking for that common case. So I'd prefer if we didn't add
> unnecessary locking in those paths and just document that for non-DAX
> faults using page lock and i_size check is enough. After all the main
> usecase of ext2 driver these days is for people with tiny devices...

Based on this comment I'm assuming you'd like the definition of dax_sem in
struct ext2_inode_info to be conditional like ext2_inode_info->xattr_sem,
correct?
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Kara Oct. 13, 2015, 5:47 p.m. UTC | #12
On Tue 13-10-15 11:33:20, Ross Zwisler wrote:
> On Tue, Oct 13, 2015 at 10:07:12AM +0200, Jan Kara wrote:
> > On Mon 12-10-15 15:41:35, Ross Zwisler wrote:
> > > On Mon, Oct 12, 2015 at 10:14:43AM +1100, Dave Chinner wrote:
> > > > 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?
> > > 
> > > Yep, I see that XFS uses the same locking to protect both DAX and non-DAX
> > > faults.  I'll add this protection to non-DAX ext2 faults as well.
> > 
> > Actually, since ext2 driver doesn't support punch hole, there is no need
> > for additional locking in non-DAX paths. So we can save some space in inode
> > and locking for that common case. So I'd prefer if we didn't add
> > unnecessary locking in those paths and just document that for non-DAX
> > faults using page lock and i_size check is enough. After all the main
> > usecase of ext2 driver these days is for people with tiny devices...
> 
> Based on this comment I'm assuming you'd like the definition of dax_sem in
> struct ext2_inode_info to be conditional like ext2_inode_info->xattr_sem,
> correct?

Yes, please. Thanks!

								Honza
Ross Zwisler Oct. 13, 2015, 10:15 p.m. UTC | #13
On Tue, Oct 13, 2015 at 12:35:44AM +0100, Eric Curtin wrote:
> Hi Ross,
> 
> For all those int ret declarations. Why not declare and initialize all
> on the same line?
> 
> Regards,
> Eric

Because the return value 'ret' is set unconditionally later in the function as
part of a call into the DAX code.  This call needs to be made after we've done
appropriate locking, though, which really is the point of the ext2 wrapper for
the DAX function.  Setting it to some random value and then unconditionally
overwriting it later in the function is a bad pattern because a) the initial
value is meaningless and b) it can hide coding errors where you are no longer
setting the variable to something meaningful.  The "warning: ‘ret’ is used
uninitialized in this function" warnings would otherwise warn you that you've
made a mistake.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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
+ */
 static int ext2_dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
-	return dax_fault(vma, vmf, ext2_get_block, NULL);
+	struct inode *inode = file_inode(vma->vm_file);
+	struct ext2_inode_info *ei = EXT2_I(inode);
+	int ret;
+
+	down_read(&ei->dax_sem);
+	ret = dax_fault(vma, vmf, ext2_get_block, NULL);
+	up_read(&ei->dax_sem);
+	return ret;
 }
 
 static int ext2_dax_pmd_fault(struct vm_area_struct *vma, unsigned long addr,
 						pmd_t *pmd, unsigned int flags)
 {
-	return dax_pmd_fault(vma, addr, pmd, flags, ext2_get_block, NULL);
+	struct inode *inode = file_inode(vma->vm_file);
+	struct ext2_inode_info *ei = EXT2_I(inode);
+	int ret;
+
+	down_read(&ei->dax_sem);
+	ret = dax_pmd_fault(vma, addr, pmd, flags, ext2_get_block, NULL);
+	up_read(&ei->dax_sem);
+	return ret;
 }
 
 static int ext2_dax_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
-	return dax_mkwrite(vma, vmf, ext2_get_block, NULL);
+	struct inode *inode = file_inode(vma->vm_file);
+	struct ext2_inode_info *ei = EXT2_I(inode);
+	int ret;
+
+	down_read(&ei->dax_sem);
+	ret = dax_mkwrite(vma, vmf, ext2_get_block, NULL);
+	up_read(&ei->dax_sem);
+	return ret;
+}
+
+static int ext2_dax_pfn_mkwrite(struct vm_area_struct *vma,
+		struct vm_fault *vmf)
+{
+	struct inode *inode = file_inode(vma->vm_file);
+	struct ext2_inode_info *ei = EXT2_I(inode);
+	int ret;
+
+	down_read(&ei->dax_sem);
+	ret = dax_pfn_mkwrite(vma, vmf);
+	up_read(&ei->dax_sem);
+	return ret;
 }
 
 static const struct vm_operations_struct ext2_dax_vm_ops = {
 	.fault		= ext2_dax_fault,
 	.pmd_fault	= ext2_dax_pmd_fault,
 	.page_mkwrite	= ext2_dax_mkwrite,
-	.pfn_mkwrite	= dax_pfn_mkwrite,
+	.pfn_mkwrite	= ext2_dax_pfn_mkwrite,
 };
 
 static int ext2_file_mmap(struct file *file, struct vm_area_struct *vma)
diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index c60a248..2b974fc 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
@@ -1085,6 +1085,7 @@  static void ext2_free_branches(struct inode *inode, __le32 *p, __le32 *q, int de
 		ext2_free_data(inode, p, q);
 }
 
+/* dax_sem must be held when calling this function */
 static void __ext2_truncate_blocks(struct inode *inode, loff_t offset)
 {
 	__le32 *i_data = EXT2_I(inode)->i_data;
@@ -1170,6 +1171,8 @@  do_indirects:
 
 static void ext2_truncate_blocks(struct inode *inode, loff_t offset)
 {
+	struct ext2_inode_info *ei = EXT2_I(inode);
+
 	/*
 	 * XXX: it seems like a bug here that we don't allow
 	 * IS_APPEND inode to have blocks-past-i_size trimmed off.
@@ -1185,11 +1188,15 @@  static void ext2_truncate_blocks(struct inode *inode, loff_t offset)
 		return;
 	if (IS_APPEND(inode) || IS_IMMUTABLE(inode))
 		return;
+
+	down_write(&ei->dax_sem);
 	__ext2_truncate_blocks(inode, offset);
+	up_write(&ei->dax_sem);
 }
 
 static int ext2_setsize(struct inode *inode, loff_t newsize)
 {
+	struct ext2_inode_info *ei = EXT2_I(inode);
 	int error;
 
 	if (!(S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
@@ -1213,8 +1220,10 @@  static int ext2_setsize(struct inode *inode, loff_t newsize)
 	if (error)
 		return error;
 
+	down_write(&ei->dax_sem);
 	truncate_setsize(inode, newsize);
 	__ext2_truncate_blocks(inode, newsize);
+	up_write(&ei->dax_sem);
 
 	inode->i_mtime = inode->i_ctime = CURRENT_TIME_SEC;
 	if (inode_needs_sync(inode)) {
diff --git a/fs/ext2/super.c b/fs/ext2/super.c
index 900e19c..0f3fedc 100644
--- a/fs/ext2/super.c
+++ b/fs/ext2/super.c
@@ -192,6 +192,7 @@  static void init_once(void *foo)
 	init_rwsem(&ei->xattr_sem);
 #endif
 	mutex_init(&ei->truncate_mutex);
+	init_rwsem(&ei->dax_sem);
 	inode_init_once(&ei->vfs_inode);
 }