diff for duplicates of <1531330096.15351.10.camel@intel.com> diff --git a/a/content_digest b/N1/content_digest index 8c9363a..842f881 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -26,7 +26,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 Tue, 2018-07-10 at 15:52 -0700, Dave Hansen wrote:\n" @@ -60,4 +63,4 @@ "that took the page fault. The fault could have been caused by any\n" variety of reasons including protection keys. -6578098ffabf7924f2818bbb07c1f17e3d72732cda60c4428eabc78563027be9 +8526ac4ac49f606c10ce8c17d56459bbdb2842b128781f6566ab969bd31ac25f
diff --git a/a/1.txt b/N2/1.txt index d0e5d73..e60533e 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -28,3 +28,8 @@ So this bit does not report the reason for the fault. It reports the type of access; i.e. it was a shadow-stack-load or a shadow-stack-store that took the page fault. The fault could have been caused by any variety of reasons including protection keys. + +-- +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 8c9363a..4695d34 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -26,7 +26,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 Tue, 2018-07-10 at 15:52 -0700, Dave Hansen wrote:\n" @@ -58,6 +61,11 @@ "So this bit does not report the reason for the fault. It reports the\n" "type of access; i.e. it was a shadow-stack-load or a shadow-stack-store \n" "that took the page fault. The fault could have been caused by any\n" - variety of reasons including protection keys. + "variety of reasons including protection keys.\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 -6578098ffabf7924f2818bbb07c1f17e3d72732cda60c4428eabc78563027be9 +40cc9734145565d9cea6073be2d4050da83302ba32e222b6483f7a866b51ce70
diff --git a/a/1.txt b/N3/1.txt index d0e5d73..ea54355 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -3,19 +3,19 @@ On Tue, 2018-07-10 at 15:52 -0700, Dave Hansen wrote: > > > > +++ b/arch/x86/include/asm/traps.h > > @@ -157,6 +157,7 @@ enum { -> > * bit 3 == 1: use of reserved +> > A *A A A bit 3 == 1: use of reserved > > bit detected -> > * bit 4 == 1: fault was an +> > A *A A A bit 4 == 1: fault was an > > instruction fetch -> > * bit 5 == 1: protection keys +> > A *A A A bit 5 == 1: protection keys > > block access -> > + * bit 6 == 1: shadow stack +> > + *A A A bit 6 == 1: shadow stack > > access fault -> > */ +> > A */ > Could we document this bit better? > > Is this a fault where the *processor* thought it should be a shadow -> stack fault? Or is it also set on faults to valid shadow stack PTEs +> stack fault?A A Or is it also set on faults to valid shadow stack PTEs > that just happen to fault for other reasons, say protection keys? Thanks Vedvyas for explaining this to me. diff --git a/a/content_digest b/N3/content_digest index 8c9363a..3fd9eda 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -26,7 +26,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 Tue, 2018-07-10 at 15:52 -0700, Dave Hansen wrote:\n" @@ -34,19 +37,19 @@ "> > \n" "> > +++ b/arch/x86/include/asm/traps.h\n" "> > @@ -157,6 +157,7 @@ enum {\n" - "> > \302\240 *\302\240\302\240\302\240bit 3 ==\t\t\t\t1: use of reserved\n" + "> > A *A A A bit 3 ==\t\t\t\t1: use of reserved\n" "> > bit detected\n" - "> > \302\240 *\302\240\302\240\302\240bit 4 ==\t\t\t\t1: fault was an\n" + "> > A *A A A bit 4 ==\t\t\t\t1: fault was an\n" "> > instruction fetch\n" - "> > \302\240 *\302\240\302\240\302\240bit 5 ==\t\t\t\t1: protection keys\n" + "> > A *A A A bit 5 ==\t\t\t\t1: protection keys\n" "> > block access\n" - "> > + *\302\240\302\240\302\240bit 6 ==\t\t\t\t1: shadow stack\n" + "> > + *A A A bit 6 ==\t\t\t\t1: shadow stack\n" "> > access fault\n" - "> > \302\240 */\n" + "> > A */\n" "> Could we document this bit better?\n" "> \n" "> Is this a fault where the *processor* thought it should be a shadow\n" - "> stack fault?\302\240\302\240Or is it also set on faults to valid shadow stack PTEs\n" + "> stack fault?A A Or is it also set on faults to valid shadow stack PTEs\n" "> that just happen to fault for other reasons, say protection keys?\n" "\n" "Thanks Vedvyas for explaining this to me.\n" @@ -60,4 +63,4 @@ "that took the page fault. The fault could have been caused by any\n" variety of reasons including protection keys. -6578098ffabf7924f2818bbb07c1f17e3d72732cda60c4428eabc78563027be9 +e49eb119d9c8e04f7d66ab2139387ed67809ed42c2b06f6e0d6e20e70a311c67
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.