All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Jan Kara <jack@suse.com>, Matthew Wilcox <willy@linux.intel.com>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Chinner <david@fromorbit.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	linux-nvdimm@lists.01.org,
	Matthew Wilcox <matthew.r.wilcox@intel.com>
Subject: Re: [PATCH v2 2/2] ext2: Add locking for DAX faults
Date: Wed, 14 Oct 2015 09:31:38 -0600	[thread overview]
Message-ID: <20151014153138.GA12470@linux.intel.com> (raw)
In-Reply-To: <20151014085119.GB23758@quack.suse.cz>

On Wed, Oct 14, 2015 at 10:51:19AM +0200, Jan Kara wrote:
> On Tue 13-10-15 16:25:37, 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.
> > 
> > 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>
> 
> The patch looks good to me. Feel free to add:
> 
> Reviewed-by: Jan Kara <jack@suse.com>
> 
> Or I can push the patch through my tree as it seems to be independent of
> any other changes, am I right?
> 
> 								Honza

Yep, it is independent of other patches.  It'd be great if you pushed it up
through your tree, thanks!

WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Jan Kara <jack@suse.com>, Matthew Wilcox <willy@linux.intel.com>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Chinner <david@fromorbit.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	linux-nvdimm@ml01.01.org,
	Matthew Wilcox <matthew.r.wilcox@intel.com>
Subject: Re: [PATCH v2 2/2] ext2: Add locking for DAX faults
Date: Wed, 14 Oct 2015 09:31:38 -0600	[thread overview]
Message-ID: <20151014153138.GA12470@linux.intel.com> (raw)
In-Reply-To: <20151014085119.GB23758@quack.suse.cz>

On Wed, Oct 14, 2015 at 10:51:19AM +0200, Jan Kara wrote:
> On Tue 13-10-15 16:25:37, 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.
> > 
> > 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>
> 
> The patch looks good to me. Feel free to add:
> 
> Reviewed-by: Jan Kara <jack@suse.com>
> 
> Or I can push the patch through my tree as it seems to be independent of
> any other changes, am I right?
> 
> 								Honza

Yep, it is independent of other patches.  It'd be great if you pushed it up
through your tree, thanks!

  reply	other threads:[~2015-10-14 15:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-13 22:25 [PATCH v2 0/2] Add updated DAX locking to ext2 Ross Zwisler
2015-10-13 22:25 ` Ross Zwisler
2015-10-13 22:25 ` [PATCH v2 1/2] dax: dax_pfn_mkwrite() truncate race check Ross Zwisler
2015-10-13 22:25   ` Ross Zwisler
2015-10-14  5:25   ` Dave Chinner
2015-10-14  5:25     ` Dave Chinner
2015-10-14  8:40     ` Jan Kara
2015-10-14  8:40       ` Jan Kara
2015-10-14 22:53       ` Dave Chinner
2015-10-14 22:53         ` Dave Chinner
2015-10-16  7:55         ` Jan Kara
2015-10-16  7:55           ` Jan Kara
2015-10-14 17:26     ` Ross Zwisler
2015-10-14 17:26       ` Ross Zwisler
2015-10-13 22:25 ` [PATCH v2 2/2] ext2: Add locking for DAX faults Ross Zwisler
2015-10-13 22:25   ` Ross Zwisler
2015-10-14  8:51   ` Jan Kara
2015-10-14  8:51     ` Jan Kara
2015-10-14 15:31     ` Ross Zwisler [this message]
2015-10-14 15:31       ` Ross Zwisler
2015-10-19 12:47       ` Jan Kara
2015-10-19 12: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=20151014153138.GA12470@linux.intel.com \
    --to=ross.zwisler@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=david@fromorbit.com \
    --cc=jack@suse.com \
    --cc=jack@suse.cz \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=matthew.r.wilcox@intel.com \
    --cc=viro@zeniv.linux.org.uk \
    --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 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.