All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20170501165451.GB14837@linux.intel.com>

diff --git a/a/1.txt b/N1/1.txt
index 15be054..535bcf3 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -25,10 +25,10 @@ On Tue, Apr 25, 2017 at 12:10:41PM +0200, Jan Kara wrote:
 > > Since we essentially never have unmapped DAX entries to evict from the
 > > radix tree, just remove dax_invalidate_mapping_entry().
 > > 
-> > Signed-off-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
 > > Fixes: c6dcf52c23d2 ("mm: Invalidate DAX radix tree entries only if appropriate")
-> > Reported-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
-> > Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>    [4.10+]
+> > Reported-by: Jan Kara <jack@suse.cz>
+> > Cc: <stable@vger.kernel.org>    [4.10+]
 > 
 > Just as a side note - we wouldn't really have to unmap the mapping range
 > covered by the DAX exceptional entry. It would be enough to find out
@@ -37,6 +37,10 @@ On Tue, Apr 25, 2017 at 12:10:41PM +0200, Jan Kara wrote:
 > dax_mapping_entry_mkclean() and IMHO it is not worth it. So I agree with
 > what you did. You can add:
 > 
-> Reviewed-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
+> Reviewed-by: Jan Kara <jack@suse.cz>
 
 Yep, that makes sense.  Thanks for the review.
+_______________________________________________
+Linux-nvdimm mailing list
+Linux-nvdimm@lists.01.org
+https://lists.01.org/mailman/listinfo/linux-nvdimm
diff --git a/a/content_digest b/N1/content_digest
index 38cb6cf..8f3102f 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,34 +1,33 @@
  "ref\020170420191446.GA21694@linux.intel.com\0"
  "ref\020170421034437.4359-1-ross.zwisler@linux.intel.com\0"
  "ref\020170425101041.GG2793@quack2.suse.cz\0"
- "ref\020170425101041.GG2793-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org\0"
- "From\0Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>\0"
+ "From\0Ross Zwisler <ross.zwisler@linux.intel.com>\0"
  "Subject\0Re: [PATCH 1/2] dax: prevent invalidation of mapped DAX entries\0"
  "Date\0Mon, 1 May 2017 10:54:51 -0600\0"
- "To\0Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>\0"
- "Cc\0Latchesar Ionkov <lucho-OnYtXJJ0/fesTnJN9+BGXg@public.gmane.org>"
-  Trond Myklebust <trond.myklebust-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
-  linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
-  Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
-  linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Matthew Wilcox <mawilcox-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
-  Andrey Ryabinin <aryabinin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
-  Eric Van Hensbergen <ericvh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
-  linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
-  Alexander Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
-  v9fs-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
-  Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
-  linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Darrick J. Wong <darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
-  samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org
-  linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Steve French <sfrench-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
-  Alexey Kuznetsov <kuznet-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
-  Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
-  linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Ron Minnich <rminnich-4OHPYypu0djtX7QSmKvirg@public.gmane.org>
-  Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
- " Anna Schumaker <anna.schumaker-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>\0"
+ "To\0Jan Kara <jack@suse.cz>\0"
+ "Cc\0Latchesar Ionkov <lucho@ionkov.net>"
+  Trond Myklebust <trond.myklebust@primarydata.com>
+  linux-mm@kvack.org
+  Christoph Hellwig <hch@lst.de>
+  linux-cifs@vger.kernel.org
+  Matthew Wilcox <mawilcox@microsoft.com>
+  Andrey Ryabinin <aryabinin@virtuozzo.com>
+  Eric Van Hensbergen <ericvh@gmail.com>
+  linux-nvdimm@lists.01.org
+  Alexander Viro <viro@zeniv.linux.org.uk>
+  v9fs-developer@lists.sourceforge.net
+  Jens Axboe <axboe@kernel.dk>
+  linux-nfs@vger.kernel.org
+  Darrick J. Wong <darrick.wong@oracle.com>
+  samba-technical@lists.samba.org
+  linux-kernel@vger.kernel.org
+  Steve French <sfrench@samba.org>
+  Alexey Kuznetsov <kuznet@virtuozzo.com>
+  Johannes Weiner <hannes@cmpxchg.org>
+  linux-fsdevel@vger.kernel.org
+  Ron Minnich <rminnich@sandia.gov>
+  Andrew Morton <akpm@linux-foundation.org>
+ " Anna Schumaker <anna.schumaker@netapp.com>\0"
  "\00:1\0"
  "b\0"
  "On Tue, Apr 25, 2017 at 12:10:41PM +0200, Jan Kara wrote:\n"
@@ -58,10 +57,10 @@
  "> > Since we essentially never have unmapped DAX entries to evict from the\n"
  "> > radix tree, just remove dax_invalidate_mapping_entry().\n"
  "> > \n"
- "> > Signed-off-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>\n"
+ "> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>\n"
  "> > Fixes: c6dcf52c23d2 (\"mm: Invalidate DAX radix tree entries only if appropriate\")\n"
- "> > Reported-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>\n"
- "> > Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>    [4.10+]\n"
+ "> > Reported-by: Jan Kara <jack@suse.cz>\n"
+ "> > Cc: <stable@vger.kernel.org>    [4.10+]\n"
  "> \n"
  "> Just as a side note - we wouldn't really have to unmap the mapping range\n"
  "> covered by the DAX exceptional entry. It would be enough to find out\n"
@@ -70,8 +69,12 @@
  "> dax_mapping_entry_mkclean() and IMHO it is not worth it. So I agree with\n"
  "> what you did. You can add:\n"
  "> \n"
- "> Reviewed-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>\n"
+ "> Reviewed-by: Jan Kara <jack@suse.cz>\n"
  "\n"
- Yep, that makes sense.  Thanks for the review.
+ "Yep, that makes sense.  Thanks for the review.\n"
+ "_______________________________________________\n"
+ "Linux-nvdimm mailing list\n"
+ "Linux-nvdimm@lists.01.org\n"
+ https://lists.01.org/mailman/listinfo/linux-nvdimm
 
-4676c78bcb09ac989387518b08fbcb68f9ef4928927a0601fdde8985b4873a17
+6a176db85f21a13e5ef6bc7e718645f49d50d3f087f6c53b078f441eb8451d20

diff --git a/a/1.txt b/N2/1.txt
index 15be054..382559f 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -25,10 +25,10 @@ On Tue, Apr 25, 2017 at 12:10:41PM +0200, Jan Kara wrote:
 > > Since we essentially never have unmapped DAX entries to evict from the
 > > radix tree, just remove dax_invalidate_mapping_entry().
 > > 
-> > Signed-off-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
 > > Fixes: c6dcf52c23d2 ("mm: Invalidate DAX radix tree entries only if appropriate")
-> > Reported-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
-> > Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>    [4.10+]
+> > Reported-by: Jan Kara <jack@suse.cz>
+> > Cc: <stable@vger.kernel.org>    [4.10+]
 > 
 > Just as a side note - we wouldn't really have to unmap the mapping range
 > covered by the DAX exceptional entry. It would be enough to find out
@@ -37,6 +37,6 @@ On Tue, Apr 25, 2017 at 12:10:41PM +0200, Jan Kara wrote:
 > dax_mapping_entry_mkclean() and IMHO it is not worth it. So I agree with
 > what you did. You can add:
 > 
-> Reviewed-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
+> Reviewed-by: Jan Kara <jack@suse.cz>
 
 Yep, that makes sense.  Thanks for the review.
diff --git a/a/content_digest b/N2/content_digest
index 38cb6cf..6808dae 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -1,34 +1,36 @@
  "ref\020170420191446.GA21694@linux.intel.com\0"
  "ref\020170421034437.4359-1-ross.zwisler@linux.intel.com\0"
  "ref\020170425101041.GG2793@quack2.suse.cz\0"
- "ref\020170425101041.GG2793-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org\0"
- "From\0Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>\0"
+ "From\0Ross Zwisler <ross.zwisler@linux.intel.com>\0"
  "Subject\0Re: [PATCH 1/2] dax: prevent invalidation of mapped DAX entries\0"
  "Date\0Mon, 1 May 2017 10:54:51 -0600\0"
- "To\0Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>\0"
- "Cc\0Latchesar Ionkov <lucho-OnYtXJJ0/fesTnJN9+BGXg@public.gmane.org>"
-  Trond Myklebust <trond.myklebust-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
-  linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
-  Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
-  linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Matthew Wilcox <mawilcox-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
-  Andrey Ryabinin <aryabinin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
-  Eric Van Hensbergen <ericvh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
-  linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
-  Alexander Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
-  v9fs-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
-  Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
-  linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Darrick J. Wong <darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
-  samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org
-  linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Steve French <sfrench-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
-  Alexey Kuznetsov <kuznet-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
-  Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
-  linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Ron Minnich <rminnich-4OHPYypu0djtX7QSmKvirg@public.gmane.org>
-  Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
- " Anna Schumaker <anna.schumaker-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>\0"
+ "To\0Jan Kara <jack@suse.cz>\0"
+ "Cc\0Ross Zwisler <ross.zwisler@linux.intel.com>"
+  Andrew Morton <akpm@linux-foundation.org>
+  linux-kernel@vger.kernel.org
+  Alexander Viro <viro@zeniv.linux.org.uk>
+  Alexey Kuznetsov <kuznet@virtuozzo.com>
+  Andrey Ryabinin <aryabinin@virtuozzo.com>
+  Anna Schumaker <anna.schumaker@netapp.com>
+  Christoph Hellwig <hch@lst.de>
+  Dan Williams <dan.j.williams@intel.com>
+  Darrick J. Wong <darrick.wong@oracle.com>
+  Eric Van Hensbergen <ericvh@gmail.com>
+  Jens Axboe <axboe@kernel.dk>
+  Johannes Weiner <hannes@cmpxchg.org>
+  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+  Latchesar Ionkov <lucho@ionkov.net>
+  linux-cifs@vger.kernel.org
+  linux-fsdevel@vger.kernel.org
+  linux-mm@kvack.org
+  linux-nfs@vger.kernel.org
+  linux-nvdimm@lists.01.org
+  Matthew Wilcox <mawilcox@microsoft.com>
+  Ron Minnich <rminnich@sandia.gov>
+  samba-technical@lists.samba.org
+  Steve French <sfrench@samba.org>
+  Trond Myklebust <trond.myklebust@primarydata.com>
+ " v9fs-developer@lists.sourceforge.net\0"
  "\00:1\0"
  "b\0"
  "On Tue, Apr 25, 2017 at 12:10:41PM +0200, Jan Kara wrote:\n"
@@ -58,10 +60,10 @@
  "> > Since we essentially never have unmapped DAX entries to evict from the\n"
  "> > radix tree, just remove dax_invalidate_mapping_entry().\n"
  "> > \n"
- "> > Signed-off-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>\n"
+ "> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>\n"
  "> > Fixes: c6dcf52c23d2 (\"mm: Invalidate DAX radix tree entries only if appropriate\")\n"
- "> > Reported-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>\n"
- "> > Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>    [4.10+]\n"
+ "> > Reported-by: Jan Kara <jack@suse.cz>\n"
+ "> > Cc: <stable@vger.kernel.org>    [4.10+]\n"
  "> \n"
  "> Just as a side note - we wouldn't really have to unmap the mapping range\n"
  "> covered by the DAX exceptional entry. It would be enough to find out\n"
@@ -70,8 +72,8 @@
  "> dax_mapping_entry_mkclean() and IMHO it is not worth it. So I agree with\n"
  "> what you did. You can add:\n"
  "> \n"
- "> Reviewed-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>\n"
+ "> Reviewed-by: Jan Kara <jack@suse.cz>\n"
  "\n"
  Yep, that makes sense.  Thanks for the review.
 
-4676c78bcb09ac989387518b08fbcb68f9ef4928927a0601fdde8985b4873a17
+5bf74991dd313d77d994acae56efe6bb6b077f9db46b62c52cd5195cf5fa78c3

diff --git a/a/1.txt b/N3/1.txt
index 15be054..9438b8a 100644
--- a/a/1.txt
+++ b/N3/1.txt
@@ -25,10 +25,10 @@ On Tue, Apr 25, 2017 at 12:10:41PM +0200, Jan Kara wrote:
 > > Since we essentially never have unmapped DAX entries to evict from the
 > > radix tree, just remove dax_invalidate_mapping_entry().
 > > 
-> > Signed-off-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
 > > Fixes: c6dcf52c23d2 ("mm: Invalidate DAX radix tree entries only if appropriate")
-> > Reported-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
-> > Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>    [4.10+]
+> > Reported-by: Jan Kara <jack@suse.cz>
+> > Cc: <stable@vger.kernel.org>    [4.10+]
 > 
 > Just as a side note - we wouldn't really have to unmap the mapping range
 > covered by the DAX exceptional entry. It would be enough to find out
@@ -37,6 +37,12 @@ On Tue, Apr 25, 2017 at 12:10:41PM +0200, Jan Kara wrote:
 > dax_mapping_entry_mkclean() and IMHO it is not worth it. So I agree with
 > what you did. You can add:
 > 
-> Reviewed-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
+> Reviewed-by: Jan Kara <jack@suse.cz>
 
 Yep, that makes sense.  Thanks for the review.
+
+--
+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>
diff --git a/a/content_digest b/N3/content_digest
index 38cb6cf..2d79429 100644
--- a/a/content_digest
+++ b/N3/content_digest
@@ -1,34 +1,36 @@
  "ref\020170420191446.GA21694@linux.intel.com\0"
  "ref\020170421034437.4359-1-ross.zwisler@linux.intel.com\0"
  "ref\020170425101041.GG2793@quack2.suse.cz\0"
- "ref\020170425101041.GG2793-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org\0"
- "From\0Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>\0"
+ "From\0Ross Zwisler <ross.zwisler@linux.intel.com>\0"
  "Subject\0Re: [PATCH 1/2] dax: prevent invalidation of mapped DAX entries\0"
  "Date\0Mon, 1 May 2017 10:54:51 -0600\0"
- "To\0Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>\0"
- "Cc\0Latchesar Ionkov <lucho-OnYtXJJ0/fesTnJN9+BGXg@public.gmane.org>"
-  Trond Myklebust <trond.myklebust-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
-  linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
-  Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
-  linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Matthew Wilcox <mawilcox-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
-  Andrey Ryabinin <aryabinin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
-  Eric Van Hensbergen <ericvh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
-  linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
-  Alexander Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
-  v9fs-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
-  Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
-  linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Darrick J. Wong <darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
-  samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org
-  linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Steve French <sfrench-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
-  Alexey Kuznetsov <kuznet-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
-  Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
-  linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Ron Minnich <rminnich-4OHPYypu0djtX7QSmKvirg@public.gmane.org>
-  Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
- " Anna Schumaker <anna.schumaker-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>\0"
+ "To\0Jan Kara <jack@suse.cz>\0"
+ "Cc\0Ross Zwisler <ross.zwisler@linux.intel.com>"
+  Andrew Morton <akpm@linux-foundation.org>
+  linux-kernel@vger.kernel.org
+  Alexander Viro <viro@zeniv.linux.org.uk>
+  Alexey Kuznetsov <kuznet@virtuozzo.com>
+  Andrey Ryabinin <aryabinin@virtuozzo.com>
+  Anna Schumaker <anna.schumaker@netapp.com>
+  Christoph Hellwig <hch@lst.de>
+  Dan Williams <dan.j.williams@intel.com>
+  Darrick J. Wong <darrick.wong@oracle.com>
+  Eric Van Hensbergen <ericvh@gmail.com>
+  Jens Axboe <axboe@kernel.dk>
+  Johannes Weiner <hannes@cmpxchg.org>
+  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+  Latchesar Ionkov <lucho@ionkov.net>
+  linux-cifs@vger.kernel.org
+  linux-fsdevel@vger.kernel.org
+  linux-mm@kvack.org
+  linux-nfs@vger.kernel.org
+  linux-nvdimm@lists.01.org
+  Matthew Wilcox <mawilcox@microsoft.com>
+  Ron Minnich <rminnich@sandia.gov>
+  samba-technical@lists.samba.org
+  Steve French <sfrench@samba.org>
+  Trond Myklebust <trond.myklebust@primarydata.com>
+ " v9fs-developer@lists.sourceforge.net\0"
  "\00:1\0"
  "b\0"
  "On Tue, Apr 25, 2017 at 12:10:41PM +0200, Jan Kara wrote:\n"
@@ -58,10 +60,10 @@
  "> > Since we essentially never have unmapped DAX entries to evict from the\n"
  "> > radix tree, just remove dax_invalidate_mapping_entry().\n"
  "> > \n"
- "> > Signed-off-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>\n"
+ "> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>\n"
  "> > Fixes: c6dcf52c23d2 (\"mm: Invalidate DAX radix tree entries only if appropriate\")\n"
- "> > Reported-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>\n"
- "> > Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>    [4.10+]\n"
+ "> > Reported-by: Jan Kara <jack@suse.cz>\n"
+ "> > Cc: <stable@vger.kernel.org>    [4.10+]\n"
  "> \n"
  "> Just as a side note - we wouldn't really have to unmap the mapping range\n"
  "> covered by the DAX exceptional entry. It would be enough to find out\n"
@@ -70,8 +72,14 @@
  "> dax_mapping_entry_mkclean() and IMHO it is not worth it. So I agree with\n"
  "> what you did. You can add:\n"
  "> \n"
- "> Reviewed-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>\n"
+ "> Reviewed-by: Jan Kara <jack@suse.cz>\n"
  "\n"
- Yep, that makes sense.  Thanks for the review.
+ "Yep, that makes sense.  Thanks for the review.\n"
+ "\n"
+ "--\n"
+ "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n"
+ "the body to majordomo@kvack.org.  For more info on Linux MM,\n"
+ "see: http://www.linux-mm.org/ .\n"
+ "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>"
 
-4676c78bcb09ac989387518b08fbcb68f9ef4928927a0601fdde8985b4873a17
+6cb7ea4b8018c0794617b3b500a5c67b1e08e598f93b6cea8f375f93a516d52c

diff --git a/a/1.txt b/N4/1.txt
index 15be054..382559f 100644
--- a/a/1.txt
+++ b/N4/1.txt
@@ -25,10 +25,10 @@ On Tue, Apr 25, 2017 at 12:10:41PM +0200, Jan Kara wrote:
 > > Since we essentially never have unmapped DAX entries to evict from the
 > > radix tree, just remove dax_invalidate_mapping_entry().
 > > 
-> > Signed-off-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
 > > Fixes: c6dcf52c23d2 ("mm: Invalidate DAX radix tree entries only if appropriate")
-> > Reported-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
-> > Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>    [4.10+]
+> > Reported-by: Jan Kara <jack@suse.cz>
+> > Cc: <stable@vger.kernel.org>    [4.10+]
 > 
 > Just as a side note - we wouldn't really have to unmap the mapping range
 > covered by the DAX exceptional entry. It would be enough to find out
@@ -37,6 +37,6 @@ On Tue, Apr 25, 2017 at 12:10:41PM +0200, Jan Kara wrote:
 > dax_mapping_entry_mkclean() and IMHO it is not worth it. So I agree with
 > what you did. You can add:
 > 
-> Reviewed-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
+> Reviewed-by: Jan Kara <jack@suse.cz>
 
 Yep, that makes sense.  Thanks for the review.
diff --git a/a/content_digest b/N4/content_digest
index 38cb6cf..3bd6174 100644
--- a/a/content_digest
+++ b/N4/content_digest
@@ -1,34 +1,36 @@
  "ref\020170420191446.GA21694@linux.intel.com\0"
  "ref\020170421034437.4359-1-ross.zwisler@linux.intel.com\0"
  "ref\020170425101041.GG2793@quack2.suse.cz\0"
- "ref\020170425101041.GG2793-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org\0"
- "From\0Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>\0"
+ "From\0Ross Zwisler <ross.zwisler@linux.intel.com>\0"
  "Subject\0Re: [PATCH 1/2] dax: prevent invalidation of mapped DAX entries\0"
  "Date\0Mon, 1 May 2017 10:54:51 -0600\0"
- "To\0Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>\0"
- "Cc\0Latchesar Ionkov <lucho-OnYtXJJ0/fesTnJN9+BGXg@public.gmane.org>"
-  Trond Myklebust <trond.myklebust-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
-  linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
-  Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
-  linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Matthew Wilcox <mawilcox-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
-  Andrey Ryabinin <aryabinin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
-  Eric Van Hensbergen <ericvh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
-  linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
-  Alexander Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
-  v9fs-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
-  Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
-  linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Darrick J. Wong <darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
-  samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org
-  linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Steve French <sfrench-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
-  Alexey Kuznetsov <kuznet-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
-  Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
-  linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Ron Minnich <rminnich-4OHPYypu0djtX7QSmKvirg@public.gmane.org>
-  Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
- " Anna Schumaker <anna.schumaker-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>\0"
+ "To\0Jan Kara <jack@suse.cz>\0"
+ "Cc\0Ross Zwisler <ross.zwisler@linux.intel.com>"
+  Andrew Morton <akpm@linux-foundation.org>
+  linux-kernel@vger.kernel.org
+  Alexander Viro <viro@zeniv.linux.org.uk>
+  Alexey Kuznetsov <kuznet@virtuozzo.com>
+  Andrey Ryabinin <aryabinin@virtuozzo.com>
+  Anna Schumaker <anna.schumaker@netapp.com>
+  Christoph Hellwig <hch@lst.de>
+  Dan Williams <dan.j.williams@intel.com>
+  Darrick J. Wong <darrick.wong@oracle.com>
+  Eric Van Hensbergen <ericvh@gmail.com>
+  Jens Axboe <axboe@kernel.dk>
+  Johannes Weiner <hannes@cmpxchg.org>
+  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+  Latchesar Ionkov <lucho@ionkov.net>
+  linux-cifs@vger.kernel.org
+  linux-fsdevel@vger.kernel.org
+  linux-mm@kvack.org
+  linux-nfs@vger.kernel.org
+  linux-nvdimm@ml01.01.org
+  Matthew Wilcox <mawilcox@microsoft.com>
+  Ron Minnich <rminnich@sandia.gov>
+  samba-technical@lists.samba.org
+  Steve French <sfrench@samba.org>
+  Trond Myklebust <trond.myklebust@primarydata.com>
+ " v9fs-developer@lists.sourceforge.net\0"
  "\00:1\0"
  "b\0"
  "On Tue, Apr 25, 2017 at 12:10:41PM +0200, Jan Kara wrote:\n"
@@ -58,10 +60,10 @@
  "> > Since we essentially never have unmapped DAX entries to evict from the\n"
  "> > radix tree, just remove dax_invalidate_mapping_entry().\n"
  "> > \n"
- "> > Signed-off-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>\n"
+ "> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>\n"
  "> > Fixes: c6dcf52c23d2 (\"mm: Invalidate DAX radix tree entries only if appropriate\")\n"
- "> > Reported-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>\n"
- "> > Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>    [4.10+]\n"
+ "> > Reported-by: Jan Kara <jack@suse.cz>\n"
+ "> > Cc: <stable@vger.kernel.org>    [4.10+]\n"
  "> \n"
  "> Just as a side note - we wouldn't really have to unmap the mapping range\n"
  "> covered by the DAX exceptional entry. It would be enough to find out\n"
@@ -70,8 +72,8 @@
  "> dax_mapping_entry_mkclean() and IMHO it is not worth it. So I agree with\n"
  "> what you did. You can add:\n"
  "> \n"
- "> Reviewed-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>\n"
+ "> Reviewed-by: Jan Kara <jack@suse.cz>\n"
  "\n"
  Yep, that makes sense.  Thanks for the review.
 
-4676c78bcb09ac989387518b08fbcb68f9ef4928927a0601fdde8985b4873a17
+814b57c150e037ce5ae6dfaf3f79b3fa003dda6dcb363f45f697ffe96312b1fb

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.