All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Jan Kara <jack@suse.cz>, Ashok Raj <ashok.raj@intel.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-rdma@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Joerg Roedel <joro@8bytes.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	Dave Chinner <david@fromorbit.com>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-xfs@vger.kernel.org, Linux MM <linux-mm@kvack.org>,
	Linux API <linux-api@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v7 07/12] dma-mapping: introduce dma_has_iommu()
Date: Tue, 10 Oct 2017 11:25:16 -0600	[thread overview]
Message-ID: <20171010172516.GA29915@obsidianresearch.com> (raw)
In-Reply-To: <CAPcyv4h_uQGBAX6-bMkkZLO_YyQ6t4n_b8tH8wU_P0Jh23N5MQ@mail.gmail.com>

On Mon, Oct 09, 2017 at 12:28:29PM -0700, Dan Williams wrote:

> > I don't think this has ever come up in the context of an all-device MR
> > invalidate requirement. Drivers already have code to invalidate
> > specifc MRs, but to find all MRs that touch certain pages and then
> > invalidate them would be new code.
> >
> > We also have ODP aware drivers that can retarget a MR to new
> > physical pages. If the block map changes DAX should synchronously
> > retarget the ODP MR, not halt DMA.
> 
> Have a look at the patch [1], I don't touch the ODP path.

But, does ODP work OK already? I'm not clear on that..

> > Most likely ODP & DAX would need to be used together to get robust
> > user applications, as having the user QP's go to an error state at
> > random times (due to DMA failures) during operation is never going to
> > be acceptable...
> 
> It's not random. The process that set up the mapping and registered
> the memory gets SIGIO when someone else tries to modify the file map.
> That process then gets /proc/sys/fs/lease-break-time seconds to fix
> the problem before the kernel force revokes the DMA access.

Well, the process can't fix the problem in bounded time, so it is
random if it will fail or not.

MR life time is under the control of the remote side, and time to
complete the network exchanges required to release the MRs is hard to
bound. So even if I implement SIGIO properly my app will still likely
have random QP failures under various cases and work loads. :(

This is why ODP should be the focus because this cannot work fully
reliably otherwise..

> > Perhaps you might want to initially only support ODP MR mappings with
> > DAX and then the DMA fencing issue goes away?
> 
> I'd rather try to fix the non-ODP DAX case instead of just turning it off.

Well, what about using SIGKILL if the lease-break-time hits? The
kernel will clean up the MRs when the process exits and this will
fence DMA to that memory.

But, still, if you really want to be fined graned, then I think
invalidating the impacted MR's is a better solution for RDMA than
trying to do it with the IOMMU...

Jason
_______________________________________________
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: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>,
	Ashok Raj <ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	"Darrick J. Wong"
	<darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Greg Kroah-Hartman
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>,
	"linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org"
	<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>,
	Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>,
	Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>,
	linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linux MM <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
	Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-fsdevel
	<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
	Marek Szyprowski
	<m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH v7 07/12] dma-mapping: introduce dma_has_iommu()
Date: Tue, 10 Oct 2017 11:25:16 -0600	[thread overview]
Message-ID: <20171010172516.GA29915@obsidianresearch.com> (raw)
In-Reply-To: <CAPcyv4h_uQGBAX6-bMkkZLO_YyQ6t4n_b8tH8wU_P0Jh23N5MQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Mon, Oct 09, 2017 at 12:28:29PM -0700, Dan Williams wrote:

> > I don't think this has ever come up in the context of an all-device MR
> > invalidate requirement. Drivers already have code to invalidate
> > specifc MRs, but to find all MRs that touch certain pages and then
> > invalidate them would be new code.
> >
> > We also have ODP aware drivers that can retarget a MR to new
> > physical pages. If the block map changes DAX should synchronously
> > retarget the ODP MR, not halt DMA.
> 
> Have a look at the patch [1], I don't touch the ODP path.

But, does ODP work OK already? I'm not clear on that..

> > Most likely ODP & DAX would need to be used together to get robust
> > user applications, as having the user QP's go to an error state at
> > random times (due to DMA failures) during operation is never going to
> > be acceptable...
> 
> It's not random. The process that set up the mapping and registered
> the memory gets SIGIO when someone else tries to modify the file map.
> That process then gets /proc/sys/fs/lease-break-time seconds to fix
> the problem before the kernel force revokes the DMA access.

Well, the process can't fix the problem in bounded time, so it is
random if it will fail or not.

MR life time is under the control of the remote side, and time to
complete the network exchanges required to release the MRs is hard to
bound. So even if I implement SIGIO properly my app will still likely
have random QP failures under various cases and work loads. :(

This is why ODP should be the focus because this cannot work fully
reliably otherwise..

> > Perhaps you might want to initially only support ODP MR mappings with
> > DAX and then the DMA fencing issue goes away?
> 
> I'd rather try to fix the non-ODP DAX case instead of just turning it off.

Well, what about using SIGKILL if the lease-break-time hits? The
kernel will clean up the MRs when the process exits and this will
fence DMA to that memory.

But, still, if you really want to be fined graned, then I think
invalidating the impacted MR's is a better solution for RDMA than
trying to do it with the IOMMU...

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	Jan Kara <jack@suse.cz>, Ashok Raj <ashok.raj@intel.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-rdma@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Joerg Roedel <joro@8bytes.org>,
	Dave Chinner <david@fromorbit.com>,
	linux-xfs@vger.kernel.org, Linux MM <linux-mm@kvack.org>,
	Jeff Moyer <jmoyer@redhat.com>,
	Linux API <linux-api@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v7 07/12] dma-mapping: introduce dma_has_iommu()
Date: Tue, 10 Oct 2017 11:25:16 -0600	[thread overview]
Message-ID: <20171010172516.GA29915@obsidianresearch.com> (raw)
In-Reply-To: <CAPcyv4h_uQGBAX6-bMkkZLO_YyQ6t4n_b8tH8wU_P0Jh23N5MQ@mail.gmail.com>

On Mon, Oct 09, 2017 at 12:28:29PM -0700, Dan Williams wrote:

> > I don't think this has ever come up in the context of an all-device MR
> > invalidate requirement. Drivers already have code to invalidate
> > specifc MRs, but to find all MRs that touch certain pages and then
> > invalidate them would be new code.
> >
> > We also have ODP aware drivers that can retarget a MR to new
> > physical pages. If the block map changes DAX should synchronously
> > retarget the ODP MR, not halt DMA.
> 
> Have a look at the patch [1], I don't touch the ODP path.

But, does ODP work OK already? I'm not clear on that..

> > Most likely ODP & DAX would need to be used together to get robust
> > user applications, as having the user QP's go to an error state at
> > random times (due to DMA failures) during operation is never going to
> > be acceptable...
> 
> It's not random. The process that set up the mapping and registered
> the memory gets SIGIO when someone else tries to modify the file map.
> That process then gets /proc/sys/fs/lease-break-time seconds to fix
> the problem before the kernel force revokes the DMA access.

Well, the process can't fix the problem in bounded time, so it is
random if it will fail or not.

MR life time is under the control of the remote side, and time to
complete the network exchanges required to release the MRs is hard to
bound. So even if I implement SIGIO properly my app will still likely
have random QP failures under various cases and work loads. :(

This is why ODP should be the focus because this cannot work fully
reliably otherwise..

> > Perhaps you might want to initially only support ODP MR mappings with
> > DAX and then the DMA fencing issue goes away?
> 
> I'd rather try to fix the non-ODP DAX case instead of just turning it off.

Well, what about using SIGKILL if the lease-break-time hits? The
kernel will clean up the MRs when the process exits and this will
fence DMA to that memory.

But, still, if you really want to be fined graned, then I think
invalidating the impacted MR's is a better solution for RDMA than
trying to do it with the IOMMU...

Jason

--
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: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	Jan Kara <jack@suse.cz>, Ashok Raj <ashok.raj@intel.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-rdma@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Joerg Roedel <joro@8bytes.org>,
	Dave Chinner <david@fromorbit.com>,
	linux-xfs@vger.kernel.org, Linux MM <linux-mm@kvack.org>,
	Jeff Moyer <jmoyer@redhat.com>,
	Linux API <linux-api@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v7 07/12] dma-mapping: introduce dma_has_iommu()
Date: Tue, 10 Oct 2017 11:25:16 -0600	[thread overview]
Message-ID: <20171010172516.GA29915@obsidianresearch.com> (raw)
In-Reply-To: <CAPcyv4h_uQGBAX6-bMkkZLO_YyQ6t4n_b8tH8wU_P0Jh23N5MQ@mail.gmail.com>

On Mon, Oct 09, 2017 at 12:28:29PM -0700, Dan Williams wrote:

> > I don't think this has ever come up in the context of an all-device MR
> > invalidate requirement. Drivers already have code to invalidate
> > specifc MRs, but to find all MRs that touch certain pages and then
> > invalidate them would be new code.
> >
> > We also have ODP aware drivers that can retarget a MR to new
> > physical pages. If the block map changes DAX should synchronously
> > retarget the ODP MR, not halt DMA.
> 
> Have a look at the patch [1], I don't touch the ODP path.

But, does ODP work OK already? I'm not clear on that..

> > Most likely ODP & DAX would need to be used together to get robust
> > user applications, as having the user QP's go to an error state at
> > random times (due to DMA failures) during operation is never going to
> > be acceptable...
> 
> It's not random. The process that set up the mapping and registered
> the memory gets SIGIO when someone else tries to modify the file map.
> That process then gets /proc/sys/fs/lease-break-time seconds to fix
> the problem before the kernel force revokes the DMA access.

Well, the process can't fix the problem in bounded time, so it is
random if it will fail or not.

MR life time is under the control of the remote side, and time to
complete the network exchanges required to release the MRs is hard to
bound. So even if I implement SIGIO properly my app will still likely
have random QP failures under various cases and work loads. :(

This is why ODP should be the focus because this cannot work fully
reliably otherwise..

> > Perhaps you might want to initially only support ODP MR mappings with
> > DAX and then the DMA fencing issue goes away?
> 
> I'd rather try to fix the non-ODP DAX case instead of just turning it off.

Well, what about using SIGKILL if the lease-break-time hits? The
kernel will clean up the MRs when the process exits and this will
fence DMA to that memory.

But, still, if you really want to be fined graned, then I think
invalidating the impacted MR's is a better solution for RDMA than
trying to do it with the IOMMU...

Jason

  reply	other threads:[~2017-10-10 17:22 UTC|newest]

Thread overview: 158+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-06 22:35 [PATCH v7 00/12] MAP_DIRECT for DAX RDMA and userspace flush Dan Williams
2017-10-06 22:35 ` Dan Williams
2017-10-06 22:35 ` Dan Williams
2017-10-06 22:35 ` Dan Williams
2017-10-06 22:35 ` [PATCH v7 01/12] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-06 22:35 ` [PATCH v7 02/12] fs, mm: pass fd to ->mmap_validate() Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-06 22:35 ` [PATCH v7 03/12] fs: introduce i_mapdcount Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-09  3:08   ` Dave Chinner
2017-10-09  3:08     ` Dave Chinner
2017-10-09  3:08     ` Dave Chinner
2017-10-09  3:08     ` Dave Chinner
2017-10-06 22:35 ` [PATCH v7 04/12] fs: MAP_DIRECT core Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-06 22:35 ` [PATCH v7 05/12] xfs: prepare xfs_break_layouts() for reuse with MAP_DIRECT Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-06 22:35 ` [PATCH v7 06/12] xfs: wire up MAP_DIRECT Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-09  3:40   ` Dave Chinner
2017-10-09  3:40     ` Dave Chinner
2017-10-09  3:40     ` Dave Chinner
2017-10-09 17:08     ` Dan Williams
2017-10-09 17:08       ` Dan Williams
2017-10-09 17:08       ` Dan Williams
2017-10-09 22:50       ` Dave Chinner
2017-10-09 22:50         ` Dave Chinner
2017-10-06 22:35 ` [PATCH v7 07/12] dma-mapping: introduce dma_has_iommu() Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-06 22:35   ` Dan Williams
2017-10-06 22:45   ` David Woodhouse
2017-10-06 22:45     ` David Woodhouse
2017-10-06 22:45     ` David Woodhouse
2017-10-06 22:52     ` Dan Williams
2017-10-06 22:52       ` Dan Williams
2017-10-06 22:52       ` Dan Williams
2017-10-06 22:52       ` Dan Williams
2017-10-06 23:10       ` David Woodhouse
2017-10-06 23:10         ` David Woodhouse
2017-10-06 23:10         ` David Woodhouse
2017-10-06 23:15         ` Dan Williams
2017-10-06 23:15           ` Dan Williams
2017-10-06 23:15           ` Dan Williams
2017-10-06 23:15           ` Dan Williams
2017-10-07 11:08           ` David Woodhouse
2017-10-07 11:08             ` David Woodhouse
2017-10-07 23:33             ` Dan Williams
2017-10-07 23:33               ` Dan Williams
2017-10-07 23:33               ` Dan Williams
2017-10-07 23:33               ` Dan Williams
2017-10-06 23:12       ` Dan Williams
2017-10-06 23:12         ` Dan Williams
2017-10-08  3:45   ` [PATCH v8] dma-mapping: introduce dma_get_iommu_domain() Dan Williams
2017-10-08  3:45     ` Dan Williams
2017-10-08  3:45     ` Dan Williams
2017-10-09 10:37     ` Robin Murphy
2017-10-09 10:37       ` Robin Murphy
2017-10-09 10:37       ` Robin Murphy
2017-10-09 10:37       ` Robin Murphy
2017-10-09 17:32       ` Dan Williams
2017-10-09 17:32         ` Dan Williams
2017-10-10 14:40     ` Raj, Ashok
2017-10-10 14:40       ` Raj, Ashok
2017-10-09 18:58   ` [PATCH v7 07/12] dma-mapping: introduce dma_has_iommu() Jason Gunthorpe
2017-10-09 18:58     ` Jason Gunthorpe
2017-10-09 18:58     ` Jason Gunthorpe
2017-10-09 18:58     ` Jason Gunthorpe
2017-10-09 19:05     ` Dan Williams
2017-10-09 19:05       ` Dan Williams
2017-10-09 19:18       ` Jason Gunthorpe
2017-10-09 19:18         ` Jason Gunthorpe
2017-10-09 19:18         ` Jason Gunthorpe
2017-10-09 19:18         ` Jason Gunthorpe
2017-10-09 19:28         ` Dan Williams
2017-10-09 19:28           ` Dan Williams
2017-10-09 19:28           ` Dan Williams
2017-10-09 19:28           ` Dan Williams
2017-10-10 17:25           ` Jason Gunthorpe [this message]
2017-10-10 17:25             ` Jason Gunthorpe
2017-10-10 17:25             ` Jason Gunthorpe
2017-10-10 17:25             ` Jason Gunthorpe
2017-10-10 17:39             ` Dan Williams
2017-10-10 17:39               ` Dan Williams
2017-10-10 17:39               ` Dan Williams
2017-10-10 17:39               ` Dan Williams
2017-10-10 18:05               ` Jason Gunthorpe
2017-10-10 18:05                 ` Jason Gunthorpe
2017-10-10 18:05                 ` Jason Gunthorpe
2017-10-10 18:05                 ` Jason Gunthorpe
2017-10-10 20:17                 ` Dan Williams
2017-10-10 20:17                   ` Dan Williams
2017-10-10 20:17                   ` Dan Williams
2017-10-12 18:27                   ` Jason Gunthorpe
2017-10-12 18:27                     ` Jason Gunthorpe
2017-10-12 18:27                     ` Jason Gunthorpe
2017-10-12 20:10                     ` Dan Williams
2017-10-12 20:10                       ` Dan Williams
2017-10-13  6:50                       ` Christoph Hellwig
2017-10-13  6:50                         ` Christoph Hellwig
2017-10-13  6:50                         ` Christoph Hellwig
2017-10-13 15:03                         ` Jason Gunthorpe
2017-10-13 15:03                           ` Jason Gunthorpe
2017-10-13 15:03                           ` Jason Gunthorpe
2017-10-13 15:03                           ` Jason Gunthorpe
2017-10-15 15:14                           ` Matan Barak
2017-10-15 15:14                             ` Matan Barak
2017-10-15 15:14                             ` Matan Barak
2017-10-15 15:14                             ` Matan Barak
2017-10-15 15:21                             ` Dan Williams
2017-10-15 15:21                               ` Dan Williams
2017-10-15 15:21                               ` Dan Williams
2017-10-13  7:09         ` Christoph Hellwig
2017-10-13  7:09           ` Christoph Hellwig
2017-10-13  7:09           ` Christoph Hellwig
2017-10-06 22:36 ` [PATCH v7 08/12] fs, mapdirect: introduce ->lease_direct() Dan Williams
2017-10-06 22:36   ` Dan Williams
2017-10-06 22:36   ` Dan Williams
2017-10-06 22:36   ` Dan Williams
2017-10-06 22:36 ` [PATCH v7 09/12] xfs: wire up ->lease_direct() Dan Williams
2017-10-06 22:36   ` Dan Williams
2017-10-06 22:36   ` Dan Williams
2017-10-09  3:45   ` Dave Chinner
2017-10-09  3:45     ` Dave Chinner
2017-10-09  3:45     ` Dave Chinner
2017-10-09  3:45     ` Dave Chinner
2017-10-09 17:10     ` Dan Williams
2017-10-09 17:10       ` Dan Williams
2017-10-06 22:36 ` [PATCH v7 10/12] device-dax: " Dan Williams
2017-10-06 22:36   ` Dan Williams
2017-10-06 22:36   ` Dan Williams
2017-10-06 22:36   ` Dan Williams
2017-10-06 22:36 ` [PATCH v7 11/12] IB/core: use MAP_DIRECT to fix / enable RDMA to DAX mappings Dan Williams
2017-10-06 22:36   ` Dan Williams
2017-10-06 22:36   ` Dan Williams
2017-10-08  4:02   ` [PATCH v8 1/2] iommu: up-level sg_num_pages() from amd-iommu Dan Williams
2017-10-08  4:02     ` Dan Williams
2017-10-08  4:02     ` Dan Williams
2017-10-08  4:04   ` [PATCH v8 2/2] IB/core: use MAP_DIRECT to fix / enable RDMA to DAX mappings Dan Williams
2017-10-08  4:04     ` Dan Williams
2017-10-08  4:04     ` Dan Williams
2017-10-08  6:45     ` kbuild test robot
2017-10-08  6:45       ` kbuild test robot
2017-10-08  6:45       ` kbuild test robot
2017-10-08 15:49       ` Dan Williams
2017-10-08 15:49         ` Dan Williams
2017-10-08 15:49         ` Dan Williams
2017-10-06 22:36 ` [PATCH v7 12/12] tools/testing/nvdimm: enable rdma unit tests Dan Williams
2017-10-06 22:36   ` Dan Williams
2017-10-06 22:36   ` Dan Williams

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=20171010172516.GA29915@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --cc=ashok.raj@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=dwmw2@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=joro@8bytes.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=robin.murphy@arm.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.