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

diff --git a/a/content_digest b/N1/content_digest
index ae8123d..90806b9 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -32,7 +32,9 @@
   Nadav Amit <nadav.amit@gmail.com>
   Oleg Nesterov <oleg@redhat.com>
   Pavel Machek <pavel@ucw.cz>
- " Peter Zijlstra <peterz@infr>\0"
+  Peter Zijlstra <peterz@infradead.org>
+  Ravi V. Shankar <ravi.v.shankar@intel.com>
+ " Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>\0"
  "\00:1\0"
  "b\0"
  "On Fri, 2018-07-13 at 01:08 +0200, Thomas Gleixner wrote:\n"
@@ -98,4 +100,4 @@
  "\n"
  Yu-cheng
 
-025fcd8bfbcbb9ecad3c2de2d71d2a9354b0f43f7753172ea227fa6ac76de420
+47c7d0fe2a70dfce3a4294821efe79a3279f08375bca9aa35825692a653bb7e0

diff --git a/a/1.txt b/N2/1.txt
index e94d429..89ff81d 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -60,3 +60,8 @@ regset->core_note_type is not defined.
 We can add some comments near those enum's.
 
 Yu-cheng
+
+--
+To unsubscribe from this list: send the line "unsubscribe linux-doc" in
+the body of a message to majordomo@vger.kernel.org
+More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff --git a/a/content_digest b/N2/content_digest
index ae8123d..7ff3633 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -32,7 +32,9 @@
   Nadav Amit <nadav.amit@gmail.com>
   Oleg Nesterov <oleg@redhat.com>
   Pavel Machek <pavel@ucw.cz>
- " Peter Zijlstra <peterz@infr>\0"
+  Peter Zijlstra <peterz@infradead.org>
+  Ravi V. Shankar <ravi.v.shankar@intel.com>
+ " Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>\0"
  "\00:1\0"
  "b\0"
  "On Fri, 2018-07-13 at 01:08 +0200, Thomas Gleixner wrote:\n"
@@ -96,6 +98,11 @@
  "\n"
  "We can add some comments near those enum's.\n"
  "\n"
- Yu-cheng
+ "Yu-cheng\n"
+ "\n"
+ "--\n"
+ "To unsubscribe from this list: send the line \"unsubscribe linux-doc\" in\n"
+ "the body of a message to majordomo@vger.kernel.org\n"
+ More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
-025fcd8bfbcbb9ecad3c2de2d71d2a9354b0f43f7753172ea227fa6ac76de420
+a39edb56166ed841dfaceb1a4dbfcf299ab8e3144175d35d8ea5a79754346fe8

diff --git a/a/1.txt b/N3/1.txt
index e94d429..c468f60 100644
--- a/a/1.txt
+++ b/N3/1.txt
@@ -12,20 +12,20 @@ On Fri, 2018-07-13 at 01:08 +0200, Thomas Gleixner wrote:
 > > > > > > --- a/arch/x86/kernel/ptrace.c
 > > > > > > +++ b/arch/x86/kernel/ptrace.c
 > > > > > > @@ -49,7 +49,9 @@ enum x86_regset {
-> > > > > >  	REGSET_IOPERM64 = REGSET_XFP,
-> > > > > >  	REGSET_XSTATE,
-> > > > > >  	REGSET_TLS,
+> > > > > > A 	REGSET_IOPERM64 = REGSET_XFP,
+> > > > > > A 	REGSET_XSTATE,
+> > > > > > A 	REGSET_TLS,
 > > > > > > +	REGSET_CET64 = REGSET_TLS,
-> > > > > >  	REGSET_IOPERM32,
+> > > > > > A 	REGSET_IOPERM32,
 > > > > > > +	REGSET_CET32,
-> > > > > >  };
+> > > > > > A };
 > > > > > Why does REGSET_CET64 alias on REGSET_TLS?
-> > > > In x86_64_regsets[], there is no [REGSET_TLS].  The core dump code
+> > > > In x86_64_regsets[], there is no [REGSET_TLS]. A The core dump code
 > > > > cannot handle holes in the array.
 > > > Is there a fundamental (ABI) reason for that?
 > > What I did was, ran Linux with 'slub_debug', and forced a core dump
 > > (kill -abrt <pid>), then there was a red zone warning in the dmesg.
-> > My feeling is there could be issues in the core dump code.  These
+> > My feeling is there could be issues in the core dump code. A These
 > Kernel development is not about feelings.
 
 I got that :-)
diff --git a/a/content_digest b/N3/content_digest
index ae8123d..baca2f2 100644
--- a/a/content_digest
+++ b/N3/content_digest
@@ -32,7 +32,9 @@
   Nadav Amit <nadav.amit@gmail.com>
   Oleg Nesterov <oleg@redhat.com>
   Pavel Machek <pavel@ucw.cz>
- " Peter Zijlstra <peterz@infr>\0"
+  Peter Zijlstra <peterz@infradead.org>
+  Ravi V. Shankar <ravi.v.shankar@intel.com>
+ " Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>\0"
  "\00:1\0"
  "b\0"
  "On Fri, 2018-07-13 at 01:08 +0200, Thomas Gleixner wrote:\n"
@@ -49,20 +51,20 @@
  "> > > > > > --- a/arch/x86/kernel/ptrace.c\n"
  "> > > > > > +++ b/arch/x86/kernel/ptrace.c\n"
  "> > > > > > @@ -49,7 +49,9 @@ enum x86_regset {\n"
- "> > > > > > \302\240\tREGSET_IOPERM64 = REGSET_XFP,\n"
- "> > > > > > \302\240\tREGSET_XSTATE,\n"
- "> > > > > > \302\240\tREGSET_TLS,\n"
+ "> > > > > > A \tREGSET_IOPERM64 = REGSET_XFP,\n"
+ "> > > > > > A \tREGSET_XSTATE,\n"
+ "> > > > > > A \tREGSET_TLS,\n"
  "> > > > > > +\tREGSET_CET64 = REGSET_TLS,\n"
- "> > > > > > \302\240\tREGSET_IOPERM32,\n"
+ "> > > > > > A \tREGSET_IOPERM32,\n"
  "> > > > > > +\tREGSET_CET32,\n"
- "> > > > > > \302\240};\n"
+ "> > > > > > A };\n"
  "> > > > > Why does REGSET_CET64 alias on REGSET_TLS?\n"
- "> > > > In x86_64_regsets[], there is no [REGSET_TLS]. \302\240The core dump code\n"
+ "> > > > In x86_64_regsets[], there is no [REGSET_TLS]. A The core dump code\n"
  "> > > > cannot handle holes in the array.\n"
  "> > > Is there a fundamental (ABI) reason for that?\n"
  "> > What I did was, ran Linux with 'slub_debug', and forced a core dump\n"
  "> > (kill -abrt <pid>), then there was a red zone warning in the dmesg.\n"
- "> > My feeling is there could be issues in the core dump code. \302\240These\n"
+ "> > My feeling is there could be issues in the core dump code. A These\n"
  "> Kernel development is not about feelings.\n"
  "\n"
  "I got that :-)\n"
@@ -98,4 +100,4 @@
  "\n"
  Yu-cheng
 
-025fcd8bfbcbb9ecad3c2de2d71d2a9354b0f43f7753172ea227fa6ac76de420
+c67fcea9b5f30af824bc144060b078ca242cb240f3f6e70d326fa882b8a58d31

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.