diff for duplicates of <1531435034.2965.15.camel@intel.com> diff --git a/a/content_digest b/N1/content_digest index f9891ac..971c788 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -29,7 +29,10 @@ Mike Kravetz <mike.kravetz@oracle.com> Nadav Amit <nadav.amit@gmail.com> Oleg Nesterov <oleg@redhat.com> - " Pavel Machek <pavel@ucw.cz>Peter\0" + Pavel Machek <pavel@ucw.cz> + 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 Thu, 2018-07-12 at 16:03 +0200, Ingo Molnar wrote:\n" @@ -79,4 +82,4 @@ "\n" Yu-cheng -1289d16c52b233366284a924524289722af824016a81fa22ca24f41c465cebf5 +221b6b66bef32e589b0999910f021c6bada7fb854caeee0b02b8f66c260a1540
diff --git a/a/1.txt b/N2/1.txt index f8be4fc..ab1148b 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -44,3 +44,8 @@ Ok, I will make changes in the next version and probably revise from that if still not optimal. 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 f9891ac..12855f5 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -29,7 +29,10 @@ Mike Kravetz <mike.kravetz@oracle.com> Nadav Amit <nadav.amit@gmail.com> Oleg Nesterov <oleg@redhat.com> - " Pavel Machek <pavel@ucw.cz>Peter\0" + Pavel Machek <pavel@ucw.cz> + 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 Thu, 2018-07-12 at 16:03 +0200, Ingo Molnar wrote:\n" @@ -77,6 +80,11 @@ "Ok, I will make changes in the next version and probably revise\n" "from that if still not optimal.\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 -1289d16c52b233366284a924524289722af824016a81fa22ca24f41c465cebf5 +d9015cd77be7bba68df3a59ab6253ca56cd61c929873f4eb02b606e4edea3b2c
diff --git a/a/1.txt b/N3/1.txt index f8be4fc..bff5cde 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -9,21 +9,21 @@ On Thu, 2018-07-12 at 16:03 +0200, Ingo Molnar 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 enum's are only local to arch/x86/kernel/ptrace.c and not exported. I am not aware this is in the ABI. @@ -34,8 +34,8 @@ I am not aware this is in the ABI. > > > not to CFE? > > > > > I don't know if I can change that, will find out. -> So what I'd suggest is something pretty simple: to use CFT/cft in kernel internal -> names, except for the Intel feature bit and any MSR enumeration which can be CET +> So what I'd suggest is something pretty simple: to use CFT/cft in kernel internalA +> names, except for the Intel feature bit and any MSR enumeration which can be CETA > if Intel named it that way, and a short comment explaining the acronym difference. > > Or something like that. diff --git a/a/content_digest b/N3/content_digest index f9891ac..7d95c55 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -29,7 +29,10 @@ Mike Kravetz <mike.kravetz@oracle.com> Nadav Amit <nadav.amit@gmail.com> Oleg Nesterov <oleg@redhat.com> - " Pavel Machek <pavel@ucw.cz>Peter\0" + Pavel Machek <pavel@ucw.cz> + 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 Thu, 2018-07-12 at 16:03 +0200, Ingo Molnar wrote:\n" @@ -43,21 +46,21 @@ "> > > > --- 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" "\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" "enum's are only local to arch/x86/kernel/ptrace.c and not exported.\n" "I am not aware this is in the ABI.\n" "\n" @@ -68,8 +71,8 @@ "> > > not to CFE?\n" "> > > \n" "> > I don't know if I can change that, will find out.\n" - "> So what I'd suggest is something pretty simple: to use CFT/cft in kernel internal\302\240\n" - "> names, except for the Intel feature bit and any MSR enumeration which can be CET\302\240\n" + "> So what I'd suggest is something pretty simple: to use CFT/cft in kernel internalA \n" + "> names, except for the Intel feature bit and any MSR enumeration which can be CETA \n" "> if Intel named it that way, and a short comment explaining the acronym difference.\n" "> \n" "> Or something like that.\n" @@ -79,4 +82,4 @@ "\n" Yu-cheng -1289d16c52b233366284a924524289722af824016a81fa22ca24f41c465cebf5 +ca1cb7bede97c404a0a7af107ad8a6018f546c3b6a7414a56b3b32a9fe90673f
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.