All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20181111040102.GA204245@google.com>

diff --git a/a/1.txt b/N1/1.txt
index fbb16ef..2d25700 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,15 +1,15 @@
 On Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote:
 > 
 > 
-> > On Nov 10, 2018, at 6:38 PM, Joel Fernandes <joel@joelfernandes.org> wrote:
+> > On Nov 10, 2018, at 6:38 PM, Joel Fernandes <joel at joelfernandes.org> wrote:
 > > 
 > >> On Sat, Nov 10, 2018 at 02:18:23PM -0800, Andy Lutomirski wrote:
 > >> 
-> >>>> On Nov 10, 2018, at 2:09 PM, Joel Fernandes <joel@joelfernandes.org> wrote:
+> >>>> On Nov 10, 2018, at 2:09 PM, Joel Fernandes <joel at joelfernandes.org> wrote:
 > >>>> 
 > >>>>> On Sat, Nov 10, 2018 at 11:11:27AM -0800, Daniel Colascione wrote:
-> >>>>>> On Sat, Nov 10, 2018 at 10:45 AM, Daniel Colascione <dancol@google.com> wrote:
-> >>>>>> On Sat, Nov 10, 2018 at 10:24 AM, Joel Fernandes <joel@joelfernandes.org> wrote:
+> >>>>>> On Sat, Nov 10, 2018 at 10:45 AM, Daniel Colascione <dancol at google.com> wrote:
+> >>>>>> On Sat, Nov 10, 2018 at 10:24 AM, Joel Fernandes <joel at joelfernandes.org> wrote:
 > >>>>>> Thanks Andy for your thoughts, my comments below:
 > >>>> [snip]
 > >>>>>> I don't see it as warty, different seals will work differently. It works
diff --git a/a/content_digest b/N1/content_digest
index 68527f2..42a3c53 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -8,46 +8,23 @@
  "ref\0907D942E-E321-4BD7-BED7-ACD1D96A3643@amacapital.net\0"
  "ref\020181111023808.GA174670@google.com\0"
  "ref\0543A5181-3A16-438E-B372-97BEC48A74F8@amacapital.net\0"
- "From\0Joel Fernandes <joel@joelfernandes.org>\0"
- "Subject\0Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd\0"
+ "From\0joel at joelfernandes.org (Joel Fernandes)\0"
+ "Subject\0[PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd\0"
  "Date\0Sat, 10 Nov 2018 20:01:02 -0800\0"
- "To\0Andy Lutomirski <luto@amacapital.net>\0"
- "Cc\0Daniel Colascione <dancol@google.com>"
-  Jann Horn <jannh@google.com>
-  kernel list <linux-kernel@vger.kernel.org>
-  John Reck <jreck@google.com>
-  John Stultz <john.stultz@linaro.org>
-  Todd Kjos <tkjos@google.com>
-  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-  Christoph Hellwig <hch@infradead.org>
-  Al Viro <viro@zeniv.linux.org.uk>
-  Andrew Morton <akpm@linux-foundation.org>
-  Bruce Fields <bfields@fieldses.org>
-  Jeff Layton <jlayton@kernel.org>
-  Khalid Aziz <khalid.aziz@oracle.com>
-  Lei.Yang@windriver.com
-  linux-fsdevel@vger.kernel.org
-  linux-kselftest@vger.kernel.org
-  Linux-MM <linux-mm@kvack.org>
-  marcandre.lureau@redhat.com
-  Mike Kravetz <mike.kravetz@oracle.com>
-  Minchan Kim <minchan@kernel.org>
-  Shuah Khan <shuah@kernel.org>
- " Valdis\0"
  "\00:1\0"
  "b\0"
  "On Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote:\n"
  "> \n"
  "> \n"
- "> > On Nov 10, 2018, at 6:38 PM, Joel Fernandes <joel@joelfernandes.org> wrote:\n"
+ "> > On Nov 10, 2018, at 6:38 PM, Joel Fernandes <joel at joelfernandes.org> wrote:\n"
  "> > \n"
  "> >> On Sat, Nov 10, 2018 at 02:18:23PM -0800, Andy Lutomirski wrote:\n"
  "> >> \n"
- "> >>>> On Nov 10, 2018, at 2:09 PM, Joel Fernandes <joel@joelfernandes.org> wrote:\n"
+ "> >>>> On Nov 10, 2018, at 2:09 PM, Joel Fernandes <joel at joelfernandes.org> wrote:\n"
  "> >>>> \n"
  "> >>>>> On Sat, Nov 10, 2018 at 11:11:27AM -0800, Daniel Colascione wrote:\n"
- "> >>>>>> On Sat, Nov 10, 2018 at 10:45 AM, Daniel Colascione <dancol@google.com> wrote:\n"
- "> >>>>>> On Sat, Nov 10, 2018 at 10:24 AM, Joel Fernandes <joel@joelfernandes.org> wrote:\n"
+ "> >>>>>> On Sat, Nov 10, 2018 at 10:45 AM, Daniel Colascione <dancol at google.com> wrote:\n"
+ "> >>>>>> On Sat, Nov 10, 2018 at 10:24 AM, Joel Fernandes <joel at joelfernandes.org> wrote:\n"
  "> >>>>>> Thanks Andy for your thoughts, my comments below:\n"
  "> >>>> [snip]\n"
  "> >>>>>> I don't see it as warty, different seals will work differently. It works\n"
@@ -188,4 +165,4 @@
  "\n"
  - Joel
 
-3767fa514a963456e1776a96939616283eee057cb89a8c6fb804123b1b2f75fe
+763ea238e632b26edffc46eb0bf67cb2acdf0174f03db6fe3a642d1d0ab707a6

diff --git a/a/1.txt b/N2/1.txt
index fbb16ef..9a0a5b7 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -1,15 +1,15 @@
-On Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote:
+On Sat, Nov 10, 2018@07:40:10PM -0800, Andy Lutomirski wrote:
 > 
 > 
-> > On Nov 10, 2018, at 6:38 PM, Joel Fernandes <joel@joelfernandes.org> wrote:
+> > On Nov 10, 2018,@6:38 PM, Joel Fernandes <joel@joelfernandes.org> wrote:
 > > 
-> >> On Sat, Nov 10, 2018 at 02:18:23PM -0800, Andy Lutomirski wrote:
+> >> On Sat, Nov 10, 2018@02:18:23PM -0800, Andy Lutomirski wrote:
 > >> 
-> >>>> On Nov 10, 2018, at 2:09 PM, Joel Fernandes <joel@joelfernandes.org> wrote:
+> >>>> On Nov 10, 2018,@2:09 PM, Joel Fernandes <joel@joelfernandes.org> wrote:
 > >>>> 
-> >>>>> On Sat, Nov 10, 2018 at 11:11:27AM -0800, Daniel Colascione wrote:
-> >>>>>> On Sat, Nov 10, 2018 at 10:45 AM, Daniel Colascione <dancol@google.com> wrote:
-> >>>>>> On Sat, Nov 10, 2018 at 10:24 AM, Joel Fernandes <joel@joelfernandes.org> wrote:
+> >>>>> On Sat, Nov 10, 2018@11:11:27AM -0800, Daniel Colascione wrote:
+> >>>>>> On Sat, Nov 10, 2018@10:45 AM, Daniel Colascione <dancol@google.com> wrote:
+> >>>>>> On Sat, Nov 10, 2018@10:24 AM, Joel Fernandes <joel@joelfernandes.org> wrote:
 > >>>>>> Thanks Andy for your thoughts, my comments below:
 > >>>> [snip]
 > >>>>>> I don't see it as warty, different seals will work differently. It works
diff --git a/a/content_digest b/N2/content_digest
index 68527f2..22cc01b 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -8,46 +8,23 @@
  "ref\0907D942E-E321-4BD7-BED7-ACD1D96A3643@amacapital.net\0"
  "ref\020181111023808.GA174670@google.com\0"
  "ref\0543A5181-3A16-438E-B372-97BEC48A74F8@amacapital.net\0"
- "From\0Joel Fernandes <joel@joelfernandes.org>\0"
- "Subject\0Re: [PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd\0"
+ "From\0joel@joelfernandes.org (Joel Fernandes)\0"
+ "Subject\0[PATCH v3 resend 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd\0"
  "Date\0Sat, 10 Nov 2018 20:01:02 -0800\0"
- "To\0Andy Lutomirski <luto@amacapital.net>\0"
- "Cc\0Daniel Colascione <dancol@google.com>"
-  Jann Horn <jannh@google.com>
-  kernel list <linux-kernel@vger.kernel.org>
-  John Reck <jreck@google.com>
-  John Stultz <john.stultz@linaro.org>
-  Todd Kjos <tkjos@google.com>
-  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-  Christoph Hellwig <hch@infradead.org>
-  Al Viro <viro@zeniv.linux.org.uk>
-  Andrew Morton <akpm@linux-foundation.org>
-  Bruce Fields <bfields@fieldses.org>
-  Jeff Layton <jlayton@kernel.org>
-  Khalid Aziz <khalid.aziz@oracle.com>
-  Lei.Yang@windriver.com
-  linux-fsdevel@vger.kernel.org
-  linux-kselftest@vger.kernel.org
-  Linux-MM <linux-mm@kvack.org>
-  marcandre.lureau@redhat.com
-  Mike Kravetz <mike.kravetz@oracle.com>
-  Minchan Kim <minchan@kernel.org>
-  Shuah Khan <shuah@kernel.org>
- " Valdis\0"
  "\00:1\0"
  "b\0"
- "On Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote:\n"
+ "On Sat, Nov 10, 2018@07:40:10PM -0800, Andy Lutomirski wrote:\n"
  "> \n"
  "> \n"
- "> > On Nov 10, 2018, at 6:38 PM, Joel Fernandes <joel@joelfernandes.org> wrote:\n"
+ "> > On Nov 10, 2018,@6:38 PM, Joel Fernandes <joel@joelfernandes.org> wrote:\n"
  "> > \n"
- "> >> On Sat, Nov 10, 2018 at 02:18:23PM -0800, Andy Lutomirski wrote:\n"
+ "> >> On Sat, Nov 10, 2018@02:18:23PM -0800, Andy Lutomirski wrote:\n"
  "> >> \n"
- "> >>>> On Nov 10, 2018, at 2:09 PM, Joel Fernandes <joel@joelfernandes.org> wrote:\n"
+ "> >>>> On Nov 10, 2018,@2:09 PM, Joel Fernandes <joel@joelfernandes.org> wrote:\n"
  "> >>>> \n"
- "> >>>>> On Sat, Nov 10, 2018 at 11:11:27AM -0800, Daniel Colascione wrote:\n"
- "> >>>>>> On Sat, Nov 10, 2018 at 10:45 AM, Daniel Colascione <dancol@google.com> wrote:\n"
- "> >>>>>> On Sat, Nov 10, 2018 at 10:24 AM, Joel Fernandes <joel@joelfernandes.org> wrote:\n"
+ "> >>>>> On Sat, Nov 10, 2018@11:11:27AM -0800, Daniel Colascione wrote:\n"
+ "> >>>>>> On Sat, Nov 10, 2018@10:45 AM, Daniel Colascione <dancol@google.com> wrote:\n"
+ "> >>>>>> On Sat, Nov 10, 2018@10:24 AM, Joel Fernandes <joel@joelfernandes.org> wrote:\n"
  "> >>>>>> Thanks Andy for your thoughts, my comments below:\n"
  "> >>>> [snip]\n"
  "> >>>>>> I don't see it as warty, different seals will work differently. It works\n"
@@ -188,4 +165,4 @@
  "\n"
  - Joel
 
-3767fa514a963456e1776a96939616283eee057cb89a8c6fb804123b1b2f75fe
+dc1a333cec2907270f48b89c71cc8286b1c30db085310ae05cf2cce4dc780ac1

diff --git a/a/content_digest b/N3/content_digest
index 68527f2..d8d5790 100644
--- a/a/content_digest
+++ b/N3/content_digest
@@ -33,7 +33,9 @@
   Mike Kravetz <mike.kravetz@oracle.com>
   Minchan Kim <minchan@kernel.org>
   Shuah Khan <shuah@kernel.org>
- " Valdis\0"
+  Valdis Kletnieks <valdis.kletnieks@vt.edu>
+  Hugh Dickins <hughd@google.com>
+ " Linux API <linux-api@vger.kernel.org>\0"
  "\00:1\0"
  "b\0"
  "On Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote:\n"
@@ -188,4 +190,4 @@
  "\n"
  - Joel
 
-3767fa514a963456e1776a96939616283eee057cb89a8c6fb804123b1b2f75fe
+36f2da32d7cc56fc0427bbdd42dd8ea08448d2add950348655c9ef5542678c0c

diff --git a/a/1.txt b/N4/1.txt
index fbb16ef..0cd94ec 100644
--- a/a/1.txt
+++ b/N4/1.txt
@@ -51,7 +51,7 @@ On Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote:
 > >>>>>> 
 > >>>>>>> I see two reasonable solutions:
 > >>>>>>> 
-> >>>>>>> 1. Don’t fiddle with the struct file at all. Instead make the inode flag
+> >>>>>>> 1. Dona??t fiddle with the struct file at all. Instead make the inode flag
 > >>>>>>> work by itself.
 > >>>>>> 
 > >>>>>> Currently, the various VFS paths check only the struct file's f_mode to deny
@@ -106,7 +106,7 @@ On Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote:
 > > that in all those handlers, to check for the seal (and hope we didn't miss a
 > > file_operations handler). Is that what you are proposing?
 > 
-> The existing code already does this. That’s why I suggested grepping :)
+> The existing code already does this. Thata??s why I suggested grepping :)
 
 Ahh sorry I see your point now. Ok let me try this approach. Thank you!
 Probably we can make this work this way and it is sufficient.
@@ -123,16 +123,16 @@ will be prevented anyway and then the mmap is the only way. I'll double check
 that once I work on this idea.
 
 > > 
-> >> - add_seals won’t need the wait_for_pins and mapping_deny_write logic.
+> >> - add_seals wona??t need the wait_for_pins and mapping_deny_write logic.
 > >> 
-> >> That really should be all that’s needed.
+> >> That really should be all thata??s needed.
 > > 
 > > It seems a fair idea what you're saying. But I don't see how its less
 > > complex.. IMO its far more simple to have VFS do the denial of the operations
 > > based on the flags of its datastructures.. and if it works (which I will test
 > > to be sure it will), then we should be good.
 > 
-> I agree it’s complicated, but the code is already written.  You should just
+> I agree ita??s complicated, but the code is already written.  You should just
 > need to adjust some masks.
 > 
 
@@ -142,7 +142,7 @@ Right.
 > > Btw by any chance, are you also coming by LPC conference next week?
 > > 
 > 
-> No.  I’d like to, but I can’t make the trip this year.
+> No.  Ia??d like to, but I cana??t make the trip this year.
 
 Ok, no worries.
 
diff --git a/a/content_digest b/N4/content_digest
index 68527f2..b0a352b 100644
--- a/a/content_digest
+++ b/N4/content_digest
@@ -33,7 +33,9 @@
   Mike Kravetz <mike.kravetz@oracle.com>
   Minchan Kim <minchan@kernel.org>
   Shuah Khan <shuah@kernel.org>
- " Valdis\0"
+  Valdis Kletnieks <valdis.kletnieks@vt.edu>
+  Hugh Dickins <hughd@google.com>
+ " Linux API <linux-api@vger.kernel.org>\0"
  "\00:1\0"
  "b\0"
  "On Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote:\n"
@@ -89,7 +91,7 @@
  "> >>>>>> \n"
  "> >>>>>>> I see two reasonable solutions:\n"
  "> >>>>>>> \n"
- "> >>>>>>> 1. Don\342\200\231t fiddle with the struct file at all. Instead make the inode flag\n"
+ "> >>>>>>> 1. Dona??t fiddle with the struct file at all. Instead make the inode flag\n"
  "> >>>>>>> work by itself.\n"
  "> >>>>>> \n"
  "> >>>>>> Currently, the various VFS paths check only the struct file's f_mode to deny\n"
@@ -144,7 +146,7 @@
  "> > that in all those handlers, to check for the seal (and hope we didn't miss a\n"
  "> > file_operations handler). Is that what you are proposing?\n"
  "> \n"
- "> The existing code already does this. That\342\200\231s why I suggested grepping :)\n"
+ "> The existing code already does this. Thata??s why I suggested grepping :)\n"
  "\n"
  "Ahh sorry I see your point now. Ok let me try this approach. Thank you!\n"
  "Probably we can make this work this way and it is sufficient.\n"
@@ -161,16 +163,16 @@
  "that once I work on this idea.\n"
  "\n"
  "> > \n"
- "> >> - add_seals won\342\200\231t need the wait_for_pins and mapping_deny_write logic.\n"
+ "> >> - add_seals wona??t need the wait_for_pins and mapping_deny_write logic.\n"
  "> >> \n"
- "> >> That really should be all that\342\200\231s needed.\n"
+ "> >> That really should be all thata??s needed.\n"
  "> > \n"
  "> > It seems a fair idea what you're saying. But I don't see how its less\n"
  "> > complex.. IMO its far more simple to have VFS do the denial of the operations\n"
  "> > based on the flags of its datastructures.. and if it works (which I will test\n"
  "> > to be sure it will), then we should be good.\n"
  "> \n"
- "> I agree it\342\200\231s complicated, but the code is already written.  You should just\n"
+ "> I agree ita??s complicated, but the code is already written.  You should just\n"
  "> need to adjust some masks.\n"
  "> \n"
  "\n"
@@ -180,7 +182,7 @@
  "> > Btw by any chance, are you also coming by LPC conference next week?\n"
  "> > \n"
  "> \n"
- "> No.  I\342\200\231d like to, but I can\342\200\231t make the trip this year.\n"
+ "> No.  Ia??d like to, but I cana??t make the trip this year.\n"
  "\n"
  "Ok, no worries.\n"
  "\n"
@@ -188,4 +190,4 @@
  "\n"
  - Joel
 
-3767fa514a963456e1776a96939616283eee057cb89a8c6fb804123b1b2f75fe
+adf9886160e68d5c9077d030cbd1dd45b0c3748dea5573e90f842ece42b9249b

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.