All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	Dave Chinner <david@fromorbit.com>,
	linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org,
	linux-xfs@vger.kernel.org, linux-mm@kvack.org,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Jan Kara <jack@suse.com>,
	linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-ext4@vger.kernel.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support
Date: Fri, 7 Oct 2016 09:24:02 +0200	[thread overview]
Message-ID: <20161007072402.GB16260@quack2.suse.cz> (raw)
In-Reply-To: <20161007025833.GA2934@linux.intel.com>

On Thu 06-10-16 20:58:33, Ross Zwisler wrote:
> On Thu, Oct 06, 2016 at 03:34:24PM -0600, Ross Zwisler wrote:
> > Interesting - adding iomap_end() calls to the DAX PTE fault handler causes an
> > AA deadlock because we try and retake ei->dax_sem.  We take dax_sem in
> > ext2_dax_fault() before calling into the DAX code, then if we end up going
> > through the error path in ext2_iomap_end(), we call 
> >   ext2_write_failed()
> >     ext2_truncate_blocks()
> >       dax_sem_down_write()
> > 
> > Where we try and take dax_sem again.  This error path is really only valid for
> > I/O operations, but we happen to call it for page faults because 'written' in
> > ext2_iomap_end() is just 0.
> > 
> > So...how should we handle this?  A few ideas:
> > 
> > 1) Just continue to omit the calls to iomap_end() in the DAX page fault
> > handlers for now, and add them when there is useful work to be done in one of
> > the filesystems.
> > 
> > 2) Add an IOMAP_FAULT flag to the flags passed into iomap_begin() and
> > iomap_end() so make it explicit that we are calling as part of a fault handler
> > and not an I/O operation, and use this to adjust the error handling in
> > ext2_iomap_end().
> > 
> > 3) Just work around the existing error handling in ext2_iomap_end() by either
> > unsetting IOMAP_WRITE or by setting 'written' to the size of the fault.
> > 
> > For #2 or #3, probably add a comment explaining the deadlock and why we need
> > to never call ext2_write_failed() while handling a page fault.
> > 
> > Thoughts?
> 
> Never mind, #3 it is, I think it was just a plain bug to call iomap_end() with
> 'length' != 'written'.

Yup, that's what I'd think as well.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Jan Kara <jack@suse.cz>,
	linux-kernel@vger.kernel.org, "Theodore Ts'o" <tytso@mit.edu>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.com>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvdimm@ml01.01.org,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support
Date: Fri, 7 Oct 2016 09:24:02 +0200	[thread overview]
Message-ID: <20161007072402.GB16260@quack2.suse.cz> (raw)
In-Reply-To: <20161007025833.GA2934@linux.intel.com>

On Thu 06-10-16 20:58:33, Ross Zwisler wrote:
> On Thu, Oct 06, 2016 at 03:34:24PM -0600, Ross Zwisler wrote:
> > Interesting - adding iomap_end() calls to the DAX PTE fault handler causes an
> > AA deadlock because we try and retake ei->dax_sem.  We take dax_sem in
> > ext2_dax_fault() before calling into the DAX code, then if we end up going
> > through the error path in ext2_iomap_end(), we call 
> >   ext2_write_failed()
> >     ext2_truncate_blocks()
> >       dax_sem_down_write()
> > 
> > Where we try and take dax_sem again.  This error path is really only valid for
> > I/O operations, but we happen to call it for page faults because 'written' in
> > ext2_iomap_end() is just 0.
> > 
> > So...how should we handle this?  A few ideas:
> > 
> > 1) Just continue to omit the calls to iomap_end() in the DAX page fault
> > handlers for now, and add them when there is useful work to be done in one of
> > the filesystems.
> > 
> > 2) Add an IOMAP_FAULT flag to the flags passed into iomap_begin() and
> > iomap_end() so make it explicit that we are calling as part of a fault handler
> > and not an I/O operation, and use this to adjust the error handling in
> > ext2_iomap_end().
> > 
> > 3) Just work around the existing error handling in ext2_iomap_end() by either
> > unsetting IOMAP_WRITE or by setting 'written' to the size of the fault.
> > 
> > For #2 or #3, probably add a comment explaining the deadlock and why we need
> > to never call ext2_write_failed() while handling a page fault.
> > 
> > Thoughts?
> 
> Never mind, #3 it is, I think it was just a plain bug to call iomap_end() with
> 'length' != 'written'.

Yup, that's what I'd think as well.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Jan Kara <jack@suse.cz>,
	linux-kernel@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.com>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvdimm@lists.01.org,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support
Date: Fri, 7 Oct 2016 09:24:02 +0200	[thread overview]
Message-ID: <20161007072402.GB16260@quack2.suse.cz> (raw)
In-Reply-To: <20161007025833.GA2934@linux.intel.com>

On Thu 06-10-16 20:58:33, Ross Zwisler wrote:
> On Thu, Oct 06, 2016 at 03:34:24PM -0600, Ross Zwisler wrote:
> > Interesting - adding iomap_end() calls to the DAX PTE fault handler causes an
> > AA deadlock because we try and retake ei->dax_sem.  We take dax_sem in
> > ext2_dax_fault() before calling into the DAX code, then if we end up going
> > through the error path in ext2_iomap_end(), we call 
> >   ext2_write_failed()
> >     ext2_truncate_blocks()
> >       dax_sem_down_write()
> > 
> > Where we try and take dax_sem again.  This error path is really only valid for
> > I/O operations, but we happen to call it for page faults because 'written' in
> > ext2_iomap_end() is just 0.
> > 
> > So...how should we handle this?  A few ideas:
> > 
> > 1) Just continue to omit the calls to iomap_end() in the DAX page fault
> > handlers for now, and add them when there is useful work to be done in one of
> > the filesystems.
> > 
> > 2) Add an IOMAP_FAULT flag to the flags passed into iomap_begin() and
> > iomap_end() so make it explicit that we are calling as part of a fault handler
> > and not an I/O operation, and use this to adjust the error handling in
> > ext2_iomap_end().
> > 
> > 3) Just work around the existing error handling in ext2_iomap_end() by either
> > unsetting IOMAP_WRITE or by setting 'written' to the size of the fault.
> > 
> > For #2 or #3, probably add a comment explaining the deadlock and why we need
> > to never call ext2_write_failed() while handling a page fault.
> > 
> > Thoughts?
> 
> Never mind, #3 it is, I think it was just a plain bug to call iomap_end() with
> 'length' != 'written'.

Yup, that's what I'd think as well.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
To: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>,
	Matthew Wilcox <mawilcox-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>,
	Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>,
	linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	Andreas Dilger
	<adilger.kernel-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org>,
	Alexander Viro
	<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	Jan Kara <jack-IBi9RG/b67k@public.gmane.org>,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Subject: Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support
Date: Fri, 7 Oct 2016 09:24:02 +0200	[thread overview]
Message-ID: <20161007072402.GB16260@quack2.suse.cz> (raw)
In-Reply-To: <20161007025833.GA2934-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>

On Thu 06-10-16 20:58:33, Ross Zwisler wrote:
> On Thu, Oct 06, 2016 at 03:34:24PM -0600, Ross Zwisler wrote:
> > Interesting - adding iomap_end() calls to the DAX PTE fault handler causes an
> > AA deadlock because we try and retake ei->dax_sem.  We take dax_sem in
> > ext2_dax_fault() before calling into the DAX code, then if we end up going
> > through the error path in ext2_iomap_end(), we call 
> >   ext2_write_failed()
> >     ext2_truncate_blocks()
> >       dax_sem_down_write()
> > 
> > Where we try and take dax_sem again.  This error path is really only valid for
> > I/O operations, but we happen to call it for page faults because 'written' in
> > ext2_iomap_end() is just 0.
> > 
> > So...how should we handle this?  A few ideas:
> > 
> > 1) Just continue to omit the calls to iomap_end() in the DAX page fault
> > handlers for now, and add them when there is useful work to be done in one of
> > the filesystems.
> > 
> > 2) Add an IOMAP_FAULT flag to the flags passed into iomap_begin() and
> > iomap_end() so make it explicit that we are calling as part of a fault handler
> > and not an I/O operation, and use this to adjust the error handling in
> > ext2_iomap_end().
> > 
> > 3) Just work around the existing error handling in ext2_iomap_end() by either
> > unsetting IOMAP_WRITE or by setting 'written' to the size of the fault.
> > 
> > For #2 or #3, probably add a comment explaining the deadlock and why we need
> > to never call ext2_write_failed() while handling a page fault.
> > 
> > Thoughts?
> 
> Never mind, #3 it is, I think it was just a plain bug to call iomap_end() with
> 'length' != 'written'.

Yup, that's what I'd think as well.

								Honza
-- 
Jan Kara <jack-IBi9RG/b67k@public.gmane.org>
SUSE Labs, CR

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Jan Kara <jack@suse.cz>,
	linux-kernel@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.com>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvdimm@lists.01.org,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support
Date: Fri, 7 Oct 2016 09:24:02 +0200	[thread overview]
Message-ID: <20161007072402.GB16260@quack2.suse.cz> (raw)
In-Reply-To: <20161007025833.GA2934@linux.intel.com>

On Thu 06-10-16 20:58:33, Ross Zwisler wrote:
> On Thu, Oct 06, 2016 at 03:34:24PM -0600, Ross Zwisler wrote:
> > Interesting - adding iomap_end() calls to the DAX PTE fault handler causes an
> > AA deadlock because we try and retake ei->dax_sem.  We take dax_sem in
> > ext2_dax_fault() before calling into the DAX code, then if we end up going
> > through the error path in ext2_iomap_end(), we call 
> >   ext2_write_failed()
> >     ext2_truncate_blocks()
> >       dax_sem_down_write()
> > 
> > Where we try and take dax_sem again.  This error path is really only valid for
> > I/O operations, but we happen to call it for page faults because 'written' in
> > ext2_iomap_end() is just 0.
> > 
> > So...how should we handle this?  A few ideas:
> > 
> > 1) Just continue to omit the calls to iomap_end() in the DAX page fault
> > handlers for now, and add them when there is useful work to be done in one of
> > the filesystems.
> > 
> > 2) Add an IOMAP_FAULT flag to the flags passed into iomap_begin() and
> > iomap_end() so make it explicit that we are calling as part of a fault handler
> > and not an I/O operation, and use this to adjust the error handling in
> > ext2_iomap_end().
> > 
> > 3) Just work around the existing error handling in ext2_iomap_end() by either
> > unsetting IOMAP_WRITE or by setting 'written' to the size of the fault.
> > 
> > For #2 or #3, probably add a comment explaining the deadlock and why we need
> > to never call ext2_write_failed() while handling a page fault.
> > 
> > Thoughts?
> 
> Never mind, #3 it is, I think it was just a plain bug to call iomap_end() with
> 'length' != 'written'.

Yup, that's what I'd think as well.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2016-10-07  7:24 UTC|newest]

Thread overview: 189+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-29 22:49 [PATCH v4 00/12] re-enable DAX PMD support Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` [PATCH v4 01/12] ext4: allow DAX writeback for hole punch Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49 ` [PATCH v4 02/12] ext4: tell DAX the size of allocation holes Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49 ` [PATCH v4 03/12] dax: remove buffer_size_valid() Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-30  8:49   ` Christoph Hellwig
2016-09-30  8:49     ` Christoph Hellwig
2016-09-30  8:49     ` Christoph Hellwig
2016-09-30  8:49     ` Christoph Hellwig
2016-09-29 22:49 ` [PATCH v4 04/12] ext2: remove support for DAX PMD faults Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-30  8:49   ` Christoph Hellwig
2016-09-30  8:49     ` Christoph Hellwig
2016-09-30  8:49     ` Christoph Hellwig
2016-09-30  8:49     ` Christoph Hellwig
2016-10-03  9:35   ` Jan Kara
2016-10-03  9:35     ` Jan Kara
2016-10-03  9:35     ` Jan Kara
2016-10-03  9:35     ` Jan Kara
2016-09-29 22:49 ` [PATCH v4 05/12] dax: make 'wait_table' global variable static Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-30  8:50   ` Christoph Hellwig
2016-09-30  8:50     ` Christoph Hellwig
2016-09-30  8:50     ` Christoph Hellwig
2016-09-30  8:50     ` Christoph Hellwig
2016-10-03  9:36   ` Jan Kara
2016-10-03  9:36     ` Jan Kara
2016-10-03  9:36     ` Jan Kara
2016-10-03  9:36     ` Jan Kara
2016-10-03  9:36     ` Jan Kara
2016-09-29 22:49 ` [PATCH v4 06/12] dax: consistent variable naming for DAX entries Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-30  8:50   ` Christoph Hellwig
2016-09-30  8:50     ` Christoph Hellwig
2016-09-30  8:50     ` Christoph Hellwig
2016-09-30  8:50     ` Christoph Hellwig
2016-09-30  8:50     ` Christoph Hellwig
2016-10-03  9:37   ` Jan Kara
2016-10-03  9:37     ` Jan Kara
2016-10-03  9:37     ` Jan Kara
2016-10-03  9:37     ` Jan Kara
2016-10-03  9:37     ` Jan Kara
2016-09-29 22:49 ` [PATCH v4 07/12] dax: coordinate locking for offsets in PMD range Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-30  9:44   ` Christoph Hellwig
2016-09-30  9:44     ` Christoph Hellwig
2016-10-03  9:55   ` Jan Kara
2016-10-03  9:55     ` Jan Kara
2016-10-03  9:55     ` Jan Kara
2016-10-03  9:55     ` Jan Kara
2016-10-03 18:40     ` Ross Zwisler
2016-10-03 18:40       ` Ross Zwisler
2016-10-03 18:40       ` Ross Zwisler
2016-10-03 18:40       ` Ross Zwisler
2016-10-03 18:40       ` Ross Zwisler
2016-09-29 22:49 ` [PATCH v4 08/12] dax: remove dax_pmd_fault() Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-30  8:50   ` Christoph Hellwig
2016-09-30  8:50     ` Christoph Hellwig
2016-09-30  8:50     ` Christoph Hellwig
2016-09-30  8:50     ` Christoph Hellwig
2016-09-30  8:50     ` Christoph Hellwig
2016-10-03  9:56   ` Jan Kara
2016-10-03  9:56     ` Jan Kara
2016-10-03  9:56     ` Jan Kara
2016-10-03  9:56     ` Jan Kara
2016-09-29 22:49 ` [PATCH v4 09/12] dax: correct dax iomap code namespace Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-30  8:51   ` Christoph Hellwig
2016-09-30  8:51     ` Christoph Hellwig
2016-09-30  8:51     ` Christoph Hellwig
2016-09-30  8:51     ` Christoph Hellwig
2016-10-03  9:57   ` Jan Kara
2016-10-03  9:57     ` Jan Kara
2016-10-03  9:57     ` Jan Kara
2016-10-03  9:57     ` Jan Kara
2016-09-29 22:49 ` [PATCH v4 10/12] dax: add struct iomap based DAX PMD support Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
     [not found]   ` <1475189370-31634-11-git-send-email-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2016-09-30  9:56     ` Christoph Hellwig
2016-09-30  9:56       ` Christoph Hellwig
2016-09-30  9:56       ` Christoph Hellwig
     [not found]       ` <20160930095627.GB5299-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-10-03 21:16         ` Ross Zwisler
2016-10-03 21:16           ` Ross Zwisler
2016-10-03 21:16           ` Ross Zwisler
2016-10-03 10:59   ` Jan Kara
2016-10-03 10:59     ` Jan Kara
2016-10-03 10:59     ` Jan Kara
2016-10-03 10:59     ` Jan Kara
2016-10-03 16:37     ` Christoph Hellwig
2016-10-03 16:37       ` Christoph Hellwig
2016-10-03 16:37       ` Christoph Hellwig
2016-10-03 21:05     ` Ross Zwisler
2016-10-03 21:05       ` Ross Zwisler
2016-10-03 21:05       ` Ross Zwisler
2016-10-04  5:55       ` Jan Kara
2016-10-04  5:55         ` Jan Kara
2016-10-04  5:55         ` Jan Kara
2016-10-04  5:55         ` Jan Kara
2016-10-04 15:39         ` Ross Zwisler
2016-10-04 15:39           ` Ross Zwisler
2016-10-04 15:39           ` Ross Zwisler
2016-10-04 15:39           ` Ross Zwisler
2016-10-05  5:50           ` Jan Kara
2016-10-05  5:50             ` Jan Kara
2016-10-05  5:50             ` Jan Kara
2016-10-05  5:50             ` Jan Kara
2016-10-05  5:50             ` Jan Kara
2016-10-06 21:34       ` Ross Zwisler
2016-10-06 21:34         ` Ross Zwisler
2016-10-06 21:34         ` Ross Zwisler
2016-10-06 21:34         ` Ross Zwisler
2016-10-06 21:34         ` Ross Zwisler
2016-10-07  2:58         ` Ross Zwisler
2016-10-07  2:58           ` Ross Zwisler
2016-10-07  2:58           ` Ross Zwisler
2016-10-07  2:58           ` Ross Zwisler
2016-10-07  7:24           ` Jan Kara [this message]
2016-10-07  7:24             ` Jan Kara
2016-10-07  7:24             ` Jan Kara
2016-10-07  7:24             ` Jan Kara
2016-10-07  7:24             ` Jan Kara
2016-09-29 22:49 ` [PATCH v4 11/12] xfs: use struct iomap based DAX PMD fault path Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49 ` [PATCH v4 12/12] dax: remove "depends on BROKEN" from FS_DAX_PMD Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 22:49   ` Ross Zwisler
2016-09-29 23:43 ` [PATCH v4 00/12] re-enable DAX PMD support Dave Chinner
2016-09-29 23:43   ` Dave Chinner
2016-09-29 23:43   ` Dave Chinner
2016-09-29 23:43   ` Dave Chinner
2016-09-29 23:43   ` Dave Chinner
2016-09-30  3:03   ` Ross Zwisler
2016-09-30  3:03     ` Ross Zwisler
2016-09-30  3:03     ` Ross Zwisler
2016-09-30  3:03     ` Ross Zwisler
2016-09-30  4:00     ` Darrick J. Wong
2016-09-30  4:00       ` Darrick J. Wong
2016-10-03 18:54       ` Ross Zwisler
2016-10-03 18:54         ` Ross Zwisler
2016-09-30  6:48     ` Dave Chinner
2016-09-30  6:48       ` Dave Chinner
2016-09-30  6:48       ` Dave Chinner
2016-09-30  6:48       ` Dave Chinner
2016-10-03 21:11       ` Ross Zwisler
2016-10-03 21:11         ` Ross Zwisler
2016-10-03 21:11         ` Ross Zwisler
2016-10-03 21:11         ` Ross Zwisler
2016-10-03 23:05   ` Ross Zwisler
2016-10-03 23:05     ` Ross Zwisler
2016-10-03 23:05     ` Ross Zwisler
2016-10-03 23:05     ` Ross Zwisler
2016-09-30 11:46 ` Christoph Hellwig
2016-09-30 11:46   ` Christoph Hellwig

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=20161007072402.GB16260@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=jack@suse.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mawilcox@microsoft.com \
    --cc=ross.zwisler@linux.intel.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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.