All of lore.kernel.org
 help / color / mirror / Atom feed

diff for duplicates of <2833FD27-42A0-435C-AEA5-2DC73315867A@amacapital.net>

diff --git a/a/1.txt b/N1/1.txt
index effb9c0..076cae4 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,24 +1,21 @@
 
 > On Oct 31, 2018, at 2:58 PM, Dave Hansen <dave.hansen@intel.com> wrote:
->=20
+> 
 >> On 10/31/18 2:53 PM, Jethro Beekman wrote:
 >>> On 2018-10-31 14:35, Dave Hansen wrote:
 >>>> On 10/31/18 2:30 PM, Sean Christopherson wrote:
 >>>> AFAIK there isn't a way to prevent userspace from manually invoking
 >>>> EENTER, short of doing some really nasty text poking or PTE swizzling.
 >>>> We could declare using EENTER as unsupported,
->>>=20
+>>> 
 >>> Yep, userspace can call it all it wants, and we can also say that
 >>> calling it outside the vdso is "undefined".
->>=20
+>> 
 >> Is there a precedent for this? Are there any other ring 3 x86
 >> instructions that Linux is claiming to be "undefined" when executed by a
 >> user process?
->=20
+> 
 > We did it for MPX.  "Don't use MPX unless you first tell the kernel, or
 > we'll eat your puppy."
 
-I think EENTER in plain user code should have well defined semantics, and i=
-t should get regular signals with the appropriate bits set in the error cod=
-e field in the ucontext.  But we should probably simultaneously offer a nic=
-er API, and the libraries will use it because it=E2=80=99s nicer.=
\ No newline at end of file
+I think EENTER in plain user code should have well defined semantics, and it should get regular signals with the appropriate bits set in the error code field in the ucontext.  But we should probably simultaneously offer a nicer API, and the libraries will use it because it’s nicer.
\ No newline at end of file
diff --git a/a/content_digest b/N1/content_digest
index 61e29ec..a305704 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -82,28 +82,25 @@
 [
   "\n",
   "> On Oct 31, 2018, at 2:58 PM, Dave Hansen <dave.hansen\@intel.com> wrote:\n",
-  ">=20\n",
+  "> \n",
   ">> On 10/31/18 2:53 PM, Jethro Beekman wrote:\n",
   ">>> On 2018-10-31 14:35, Dave Hansen wrote:\n",
   ">>>> On 10/31/18 2:30 PM, Sean Christopherson wrote:\n",
   ">>>> AFAIK there isn't a way to prevent userspace from manually invoking\n",
   ">>>> EENTER, short of doing some really nasty text poking or PTE swizzling.\n",
   ">>>> We could declare using EENTER as unsupported,\n",
-  ">>>=20\n",
+  ">>> \n",
   ">>> Yep, userspace can call it all it wants, and we can also say that\n",
   ">>> calling it outside the vdso is \"undefined\".\n",
-  ">>=20\n",
+  ">> \n",
   ">> Is there a precedent for this? Are there any other ring 3 x86\n",
   ">> instructions that Linux is claiming to be \"undefined\" when executed by a\n",
   ">> user process?\n",
-  ">=20\n",
+  "> \n",
   "> We did it for MPX.  \"Don't use MPX unless you first tell the kernel, or\n",
   "> we'll eat your puppy.\"\n",
   "\n",
-  "I think EENTER in plain user code should have well defined semantics, and i=\n",
-  "t should get regular signals with the appropriate bits set in the error cod=\n",
-  "e field in the ucontext.  But we should probably simultaneously offer a nic=\n",
-  "er API, and the libraries will use it because it=E2=80=99s nicer.="
+  "I think EENTER in plain user code should have well defined semantics, and it should get regular signals with the appropriate bits set in the error code field in the ucontext.  But we should probably simultaneously offer a nicer API, and the libraries will use it because it\342\200\231s nicer."
 ]
 
-99121c390015a7a6473afa46d39e6ee57f11f67bb5d39712555f73d01c37d0d4
+0ea70b60f7c7be885cec39e22077a4e3063b85b34a522b97423276b3b7d45ae4
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.