diff for duplicates of <20180131174245.GE2912@redhat.com>

diff --git a/a/1.txt b/N1/1.txt
index 53a44e9..1e7c279 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,72 +1,53 @@
 On Wed, Jan 31, 2018 at 04:56:46PM +0000, Al Viro wrote:
 > On Mon, Jan 29, 2018 at 07:43:48PM -0500, Jerome Glisse wrote:
-> > I started a patchset about $TOPIC a while ago, right now i am working o=
-n other
-> > thing but i hope to have an RFC for $TOPIC before LSF/MM and thus would=
- like a
-> > slot during common track to talk about it as it impacts FS, BLOCK and M=
-M (i am
+> > I started a patchset about $TOPIC a while ago, right now i am working on other
+> > thing but i hope to have an RFC for $TOPIC before LSF/MM and thus would like a
+> > slot during common track to talk about it as it impacts FS, BLOCK and MM (i am
 > > assuming their will be common track).
-> > =
-
-> > Idea is that mapping (struct address_space) is available in virtualy al=
-l the
-> > places where it is needed and that their should be no reasons to depend=
- only on
-> > struct page->mapping field. My patchset basicly add mapping to a bunch =
-of vfs
-> > callback (struct address_space_operations) where it is missing, changin=
-g call
-> > site. Then i do an individual patch per filesystem to leverage the new =
-argument
+> > 
+> > Idea is that mapping (struct address_space) is available in virtualy all the
+> > places where it is needed and that their should be no reasons to depend only on
+> > struct page->mapping field. My patchset basicly add mapping to a bunch of vfs
+> > callback (struct address_space_operations) where it is missing, changing call
+> > site. Then i do an individual patch per filesystem to leverage the new argument
 > > instead on struct page.
-> =
-
-> Oh?  What about the places like fs/coda?  Or block devices, for that matt=
-er...
-> You can't count upon file->f_mapping->host =3D=3D file_inode(file).
+> 
+> Oh?  What about the places like fs/coda?  Or block devices, for that matter...
+> You can't count upon file->f_mapping->host == file_inode(file).
 
 What matter is that the place that call an address_space_operations callback
-already has mapping =3D=3D page->mapping in many places this is obvious. For
+already has mapping == page->mapping in many places this is obvious. For
 instance page just have been looked up using mapping and thus you must have
-mapping =3D=3D page->mapping. But i believe this holds in all places. They =
-are
+mapping == page->mapping. But i believe this holds in all places. They are
 few dark corners (fuse, splice, ...). Truncate also factor in all this as
 page->mapping is use to determine if a page has been truncated, but it
 should not be an issue.
 
-So i am not counting on file->f_mapping->host =3D=3D file_inode(file) but i=
- might
-count in _some_ place on vma->file->f_mapping =3D=3D page->mapping of any n=
-on private
-page inside that vma. AFAICT this holds for coda and should hold elsewhere =
-too.
+So i am not counting on file->f_mapping->host == file_inode(file) but i might
+count in _some_ place on vma->file->f_mapping == page->mapping of any non private
+page inside that vma. AFAICT this holds for coda and should hold elsewhere too.
 
-For block devices the idea is to use struct page and buffer_head (first one=
- of
+For block devices the idea is to use struct page and buffer_head (first one of
 a page) as a key to find mapping (struct address_space) back.
 
-The overall idea i have is that in any place in the kernel (except memory r=
-eclaim
-but that's ok) we can either get mapping or buffer_head information without=
- relying
-on struct page and if we have either one and a struct page then we can find=
- the
+The overall idea i have is that in any place in the kernel (except memory reclaim
+but that's ok) we can either get mapping or buffer_head information without relying
+on struct page and if we have either one and a struct page then we can find the
 other one.
 
 Like i said i am not done with a patchset for that yet so maybe i am too
-optimistic. I have another patchset i need to finish first before i go back=
- to
+optimistic. I have another patchset i need to finish first before i go back to
 this. I hope to have an RFC sometime in February or March and maybe by then
 i would have found a roadblock, i am crossing my fingers until then :)
 
-If it turns out that it is not doable i will comment on this thread and we =
-can
+If it turns out that it is not doable i will comment on this thread and we can
 kill that of from the agenda.
 
 Cheers,
-J=E9r=F4me
-_______________________________________________
-Lsf-pc mailing list
-Lsf-pc@lists.linux-foundation.org
-https://lists.linuxfoundation.org/mailman/listinfo/lsf-pc
+Jï¿½rï¿½me
+
+--
+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/N1/content_digest
index a85b57c..f44588a 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,86 +1,67 @@
  "ref\020180130004347.GD4526@redhat.com\0"
  "ref\020180131165646.GI29051@ZenIV.linux.org.uk\0"
  "From\0Jerome Glisse <jglisse@redhat.com>\0"
- "Subject\0Re: [Lsf-pc] [LSF/MM TOPIC] Killing reliance on struct page->mapping\0"
+ "Subject\0Re: [LSF/MM TOPIC] Killing reliance on struct page->mapping\0"
  "Date\0Wed, 31 Jan 2018 12:42:45 -0500\0"
  "To\0Al Viro <viro@zeniv.linux.org.uk>\0"
- "Cc\0linux-fsdevel@vger.kernel.org"
+ "Cc\0lsf-pc@lists.linux-foundation.org"
+  linux-fsdevel@vger.kernel.org
   linux-mm@kvack.org
-  lsf-pc@lists.linux-foundation.org
  " linux-block@vger.kernel.org\0"
  "\00:1\0"
  "b\0"
  "On Wed, Jan 31, 2018 at 04:56:46PM +0000, Al Viro wrote:\n"
  "> On Mon, Jan 29, 2018 at 07:43:48PM -0500, Jerome Glisse wrote:\n"
- "> > I started a patchset about $TOPIC a while ago, right now i am working o=\n"
- "n other\n"
- "> > thing but i hope to have an RFC for $TOPIC before LSF/MM and thus would=\n"
- " like a\n"
- "> > slot during common track to talk about it as it impacts FS, BLOCK and M=\n"
- "M (i am\n"
+ "> > I started a patchset about $TOPIC a while ago, right now i am working on other\n"
+ "> > thing but i hope to have an RFC for $TOPIC before LSF/MM and thus would like a\n"
+ "> > slot during common track to talk about it as it impacts FS, BLOCK and MM (i am\n"
  "> > assuming their will be common track).\n"
- "> > =\n"
- "\n"
- "> > Idea is that mapping (struct address_space) is available in virtualy al=\n"
- "l the\n"
- "> > places where it is needed and that their should be no reasons to depend=\n"
- " only on\n"
- "> > struct page->mapping field. My patchset basicly add mapping to a bunch =\n"
- "of vfs\n"
- "> > callback (struct address_space_operations) where it is missing, changin=\n"
- "g call\n"
- "> > site. Then i do an individual patch per filesystem to leverage the new =\n"
- "argument\n"
+ "> > \n"
+ "> > Idea is that mapping (struct address_space) is available in virtualy all the\n"
+ "> > places where it is needed and that their should be no reasons to depend only on\n"
+ "> > struct page->mapping field. My patchset basicly add mapping to a bunch of vfs\n"
+ "> > callback (struct address_space_operations) where it is missing, changing call\n"
+ "> > site. Then i do an individual patch per filesystem to leverage the new argument\n"
  "> > instead on struct page.\n"
- "> =\n"
- "\n"
- "> Oh?  What about the places like fs/coda?  Or block devices, for that matt=\n"
- "er...\n"
- "> You can't count upon file->f_mapping->host =3D=3D file_inode(file).\n"
+ "> \n"
+ "> Oh?  What about the places like fs/coda?  Or block devices, for that matter...\n"
+ "> You can't count upon file->f_mapping->host == file_inode(file).\n"
  "\n"
  "What matter is that the place that call an address_space_operations callback\n"
- "already has mapping =3D=3D page->mapping in many places this is obvious. For\n"
+ "already has mapping == page->mapping in many places this is obvious. For\n"
  "instance page just have been looked up using mapping and thus you must have\n"
- "mapping =3D=3D page->mapping. But i believe this holds in all places. They =\n"
- "are\n"
+ "mapping == page->mapping. But i believe this holds in all places. They are\n"
  "few dark corners (fuse, splice, ...). Truncate also factor in all this as\n"
  "page->mapping is use to determine if a page has been truncated, but it\n"
  "should not be an issue.\n"
  "\n"
- "So i am not counting on file->f_mapping->host =3D=3D file_inode(file) but i=\n"
- " might\n"
- "count in _some_ place on vma->file->f_mapping =3D=3D page->mapping of any n=\n"
- "on private\n"
- "page inside that vma. AFAICT this holds for coda and should hold elsewhere =\n"
- "too.\n"
+ "So i am not counting on file->f_mapping->host == file_inode(file) but i might\n"
+ "count in _some_ place on vma->file->f_mapping == page->mapping of any non private\n"
+ "page inside that vma. AFAICT this holds for coda and should hold elsewhere too.\n"
  "\n"
- "For block devices the idea is to use struct page and buffer_head (first one=\n"
- " of\n"
+ "For block devices the idea is to use struct page and buffer_head (first one of\n"
  "a page) as a key to find mapping (struct address_space) back.\n"
  "\n"
- "The overall idea i have is that in any place in the kernel (except memory r=\n"
- "eclaim\n"
- "but that's ok) we can either get mapping or buffer_head information without=\n"
- " relying\n"
- "on struct page and if we have either one and a struct page then we can find=\n"
- " the\n"
+ "The overall idea i have is that in any place in the kernel (except memory reclaim\n"
+ "but that's ok) we can either get mapping or buffer_head information without relying\n"
+ "on struct page and if we have either one and a struct page then we can find the\n"
  "other one.\n"
  "\n"
  "Like i said i am not done with a patchset for that yet so maybe i am too\n"
- "optimistic. I have another patchset i need to finish first before i go back=\n"
- " to\n"
+ "optimistic. I have another patchset i need to finish first before i go back to\n"
  "this. I hope to have an RFC sometime in February or March and maybe by then\n"
  "i would have found a roadblock, i am crossing my fingers until then :)\n"
  "\n"
- "If it turns out that it is not doable i will comment on this thread and we =\n"
- "can\n"
+ "If it turns out that it is not doable i will comment on this thread and we can\n"
  "kill that of from the agenda.\n"
  "\n"
  "Cheers,\n"
- "J=E9r=F4me\n"
- "_______________________________________________\n"
- "Lsf-pc mailing list\n"
- "Lsf-pc@lists.linux-foundation.org\n"
- https://lists.linuxfoundation.org/mailman/listinfo/lsf-pc
+ "J\303\257\302\277\302\275r\303\257\302\277\302\275me\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>"
 
-4b116945ed02dbfb569f4f94279abc19f52b87a568f66cc95db0dbfab865a790
+7667ca4d0e765b2a9b1e1c01bc9bc9aabed387641c900171ff133661a8362f48
