diff for duplicates of <1531325272.13297.27.camel@intel.com> diff --git a/a/content_digest b/N1/content_digest index eed46eb..1328601 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -30,7 +30,7 @@ Oleg Nesterov <oleg@redhat.com> Pavel Machek <pavel@ucw.cz> Ravi V. Shankar <ravi.v.shankar@intel.com> - " Vedvyas\0" + " Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>\0" "\00:1\0" "b\0" "On Wed, 2018-07-11 at 11:12 +0200, Peter Zijlstra wrote:\n" @@ -67,4 +67,4 @@ "\n" "Agree. \302\240I will remove the patch." -320bef52b02f7b9a05fc22a6d3bee135b23d40322f404e061a7c16fea67f597e +8ab31c70481fae4aa1f03b72426b46f204b7b054d5a3ce700ff41a3203dacf17
diff --git a/a/1.txt b/N2/1.txt index 32bf00f..fdf620e 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -31,3 +31,7 @@ On Wed, 2018-07-11 at 11:12 +0200, Peter Zijlstra wrote: > that a process wrecks itself, so what? Agree. I will remove the patch. +-- +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 eed46eb..5da205c 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -30,7 +30,7 @@ Oleg Nesterov <oleg@redhat.com> Pavel Machek <pavel@ucw.cz> Ravi V. Shankar <ravi.v.shankar@intel.com> - " Vedvyas\0" + " Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>\0" "\00:1\0" "b\0" "On Wed, 2018-07-11 at 11:12 +0200, Peter Zijlstra wrote:\n" @@ -65,6 +65,10 @@ "> Why do we need to disallow this? AFAICT the worst that can happen is\n" "> that a process wrecks itself, so what?\n" "\n" - "Agree. \302\240I will remove the patch." + "Agree. \302\240I will remove the patch.\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 -320bef52b02f7b9a05fc22a6d3bee135b23d40322f404e061a7c16fea67f597e +e3451373610d3f2972de09e9b11ddb2d91268000d3304ed82e3a67a702015b9a
diff --git a/a/1.txt b/N3/1.txt index 32bf00f..ce88f71 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -10,24 +10,24 @@ On Wed, 2018-07-11 at 11:12 +0200, Peter Zijlstra wrote: > > > +++ b/mm/mprotect.c > > > @@ -446,6 +446,15 @@ static int do_mprotect_pkey(unsigned long > > > start, size_t len, -> > > error = -ENOMEM; -> > > if (!vma) -> > > goto out; +> > > A error = -ENOMEM; +> > > A if (!vma) +> > > A goto out; > > > + > > > + /* -> > > + * Do not allow changing shadow stack memory. -> > > + */ +> > > + A * Do not allow changing shadow stack memory. +> > > + A */ > > > + if (vma->vm_flags & VM_SHSTK) { > > > + error = -EINVAL; > > > + goto out; > > > + } > > > + -> > I think this is a _bit_ draconian. Why shouldn't we be able to use -> > protection keys with a shadow stack? Or, set it to PROT_NONE? +> > I think this is a _bit_ draconian.A A Why shouldn't we be able to use +> > protection keys with a shadow stack?A A Or, set it to PROT_NONE? > Right, and then there's also madvise() and some of the other > accessors. > > Why do we need to disallow this? AFAICT the worst that can happen is > that a process wrecks itself, so what? -Agree. I will remove the patch. +Agree. A I will remove the patch. diff --git a/a/content_digest b/N3/content_digest index eed46eb..c22838e 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -30,7 +30,7 @@ Oleg Nesterov <oleg@redhat.com> Pavel Machek <pavel@ucw.cz> Ravi V. Shankar <ravi.v.shankar@intel.com> - " Vedvyas\0" + " Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>\0" "\00:1\0" "b\0" "On Wed, 2018-07-11 at 11:12 +0200, Peter Zijlstra wrote:\n" @@ -45,26 +45,26 @@ "> > > +++ b/mm/mprotect.c\n" "> > > @@ -446,6 +446,15 @@ static int do_mprotect_pkey(unsigned long\n" "> > > start, size_t len,\n" - "> > > \302\240\terror = -ENOMEM;\n" - "> > > \302\240\tif (!vma)\n" - "> > > \302\240\t\tgoto out;\n" + "> > > A \terror = -ENOMEM;\n" + "> > > A \tif (!vma)\n" + "> > > A \t\tgoto out;\n" "> > > +\n" "> > > +\t/*\n" - "> > > +\t\302\240* Do not allow changing shadow stack memory.\n" - "> > > +\t\302\240*/\n" + "> > > +\tA * Do not allow changing shadow stack memory.\n" + "> > > +\tA */\n" "> > > +\tif (vma->vm_flags & VM_SHSTK) {\n" "> > > +\t\terror = -EINVAL;\n" "> > > +\t\tgoto out;\n" "> > > +\t}\n" "> > > +\n" - "> > I think this is a _bit_ draconian.\302\240\302\240Why shouldn't we be able to use\n" - "> > protection keys with a shadow stack?\302\240\302\240Or, set it to PROT_NONE?\n" + "> > I think this is a _bit_ draconian.A A Why shouldn't we be able to use\n" + "> > protection keys with a shadow stack?A A Or, set it to PROT_NONE?\n" "> Right, and then there's also madvise() and some of the other\n" "> accessors.\n" "> \n" "> Why do we need to disallow this? AFAICT the worst that can happen is\n" "> that a process wrecks itself, so what?\n" "\n" - "Agree. \302\240I will remove the patch." + Agree. A I will remove the patch. -320bef52b02f7b9a05fc22a6d3bee135b23d40322f404e061a7c16fea67f597e +454d9872ae03a682b6355e6c984e5beb2dd886ec6f527bfc72199b57cb05b4db
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.