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

diff --git a/a/content_digest b/N1/content_digest
index 148b7a7..3134c38 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -37,7 +37,9 @@
   Mike Kravetz <mike.kravetz@oracle.com>
   Nadav Amit <nadav.amit@gmail.com>
   Oleg Nesterov <oleg@redhat.com>
- " Pavel Machek <pavel@ucw.cz>\0"
+  Pavel Machek <pavel@ucw.cz>
+  ravi.v.shankar@intel.com
+ " vedvyas.shanbhogue@intel.com\0"
  "\00:1\0"
  "b\0"
  "On Fri, 2018-09-14 at 13:46 -0700, Dave Hansen wrote:\n"
@@ -73,4 +75,4 @@
  "Would mprotect() do copy_one_pte()? \302\240Otherwise it will not go through\n"
  ptep_set_wrprotect()?
 
-5f2c039aed05f5dd8ffa7888b0463693ed80b0321776cd6ef7e385f6ec9b8bc5
+c971dff974c256b164269cf81bf5fc62d8c40186b38c95a56868268776e705dd

diff --git a/a/1.txt b/N2/1.txt
index f335d0b..1023f72 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -3,14 +3,14 @@ On Fri, 2018-09-14 at 13:46 -0700, Dave Hansen wrote:
 > > 
 > > With the updated ptep_set_wrprotect() below, I did MADV_WILLNEED to a shadow
 > > stack of 8 MB, then 10,000 fork()'s, but could not prove it is more or less
-> > efficient than the other.  So can we say this is probably fine in terms of
+> > efficient than the other. A So can we say this is probably fine in terms of
 > > efficiency?
-> Well, the first fork() will do all the hard work.  I don't think
+> Well, the first fork() will do all the hard work.A A I don't think
 > subsequent fork()s will be affected.
 
 Are you talking about a recent commit:
 
-    1b2de5d0 mm/cow: don't bother write protecting already write-protected pages
+A  A  1b2de5d0 mm/cow: don't bother write protecting already write-protected pages
 
 With that, subsequent fork()s will not do all the hard work.
 However, I have not done that for shadow stack PTEs (do we want to do that?).
@@ -28,5 +28,5 @@ I think the additional benefit for shadow stack is small?
 > 
 > might show it better.
 
-Would mprotect() do copy_one_pte()?  Otherwise it will not go through
+Would mprotect() do copy_one_pte()? A Otherwise it will not go through
 ptep_set_wrprotect()?
diff --git a/a/content_digest b/N2/content_digest
index 148b7a7..fd0defa 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -37,7 +37,9 @@
   Mike Kravetz <mike.kravetz@oracle.com>
   Nadav Amit <nadav.amit@gmail.com>
   Oleg Nesterov <oleg@redhat.com>
- " Pavel Machek <pavel@ucw.cz>\0"
+  Pavel Machek <pavel@ucw.cz>
+  ravi.v.shankar@intel.com
+ " vedvyas.shanbhogue@intel.com\0"
  "\00:1\0"
  "b\0"
  "On Fri, 2018-09-14 at 13:46 -0700, Dave Hansen wrote:\n"
@@ -45,14 +47,14 @@
  "> > \n"
  "> > With the updated ptep_set_wrprotect() below, I did MADV_WILLNEED to a shadow\n"
  "> > stack of 8 MB, then 10,000 fork()'s, but could not prove it is more or less\n"
- "> > efficient than the other. \302\240So can we say this is probably fine in terms of\n"
+ "> > efficient than the other. A So can we say this is probably fine in terms of\n"
  "> > efficiency?\n"
- "> Well, the first fork() will do all the hard work.\302\240\302\240I don't think\n"
+ "> Well, the first fork() will do all the hard work.A A I don't think\n"
  "> subsequent fork()s will be affected.\n"
  "\n"
  "Are you talking about a recent commit:\n"
  "\n"
- "\302\240 \302\240 1b2de5d0 mm/cow: don't bother write protecting already write-protected pages\n"
+ "A  A  1b2de5d0 mm/cow: don't bother write protecting already write-protected pages\n"
  "\n"
  "With that, subsequent fork()s will not do all the hard work.\n"
  "However, I have not done that for shadow stack PTEs (do we want to do that?).\n"
@@ -70,7 +72,7 @@
  "> \n"
  "> might show it better.\n"
  "\n"
- "Would mprotect() do copy_one_pte()? \302\240Otherwise it will not go through\n"
+ "Would mprotect() do copy_one_pte()? A Otherwise it will not go through\n"
  ptep_set_wrprotect()?
 
-5f2c039aed05f5dd8ffa7888b0463693ed80b0321776cd6ef7e385f6ec9b8bc5
+441a7dc22cf366afe872abc4952d95023644dc68f20b1ff008cb23233320302f

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.