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

diff --git a/a/1.txt b/N1/1.txt
index 0e7569d..28740e4 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -14,13 +14,13 @@ On Thu, 2018-07-19 at 12:05 -0700, Tadeusz Struk wrote:
 > > it?
 > > 
 > > The reason for not doing it in the interface is that it alters the
-> > ABI.  Before this patch we had a hard packet boundary: one packet
+> > ABI. ?Before this patch we had a hard packet boundary: one packet
 > > per read, one per write and a -EFAULT if you fail to provide a
-> > correctly sized buffer.  Now if you provide a buffer too small but
+> > correctly sized buffer.??Now if you provide a buffer too small but
 > > don't know about the fragmentation you're going to misprocess a
 > > packet (because you think you got a whole reply but you didn't) and
 > > then you get a -EBUSY on your next command which you don't know how
-> > to handle.  The only way out is to update the applications to
+> > to handle.??The only way out is to update the applications to
 > > handle the new behaviour, which is a no-no in Linux ABI terms.
 > 
 > Don't all the existing applications that read a response in one go
@@ -45,3 +45,8 @@ So what's wrong with fragmenting in the layer above the device driver
 (in userspace) and not actually changing the kernel?
 
 James
+
+--
+To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
+the body of a message to majordomo at vger.kernel.org
+More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff --git a/a/content_digest b/N1/content_digest
index 5431d3a..d8771a1 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -3,15 +3,10 @@
  "ref\0421c4b75-9e9d-7045-adad-797fd112898a@intel.com\0"
  "ref\01532026030.3198.2.camel@HansenPartnership.com\0"
  "ref\0e8c17a40-7e5e-61e9-7088-32817766b614@intel.com\0"
- "From\0James Bottomley <James.Bottomley@hansenpartnership.com>\0"
- "Subject\0Re: [PATCH] tpm: add support for partial reads\0"
+ "From\0James.Bottomley@hansenpartnership.com (James Bottomley)\0"
+ "Subject\0[PATCH] tpm: add support for partial reads\0"
  "Date\0Thu, 19 Jul 2018 12:52:59 -0700\0"
- "To\0Tadeusz Struk <tadeusz.struk@intel.com>"
- " jarkko.sakkinen@linux.intel.com\0"
- "Cc\0jgg@ziepe.ca"
-  linux-integrity@vger.kernel.org
-  linux-security-module@vger.kernel.org
- " linux-kernel@vger.kernel.org\0"
+ "To\0linux-security-module@vger.kernel.org\0"
  "\00:1\0"
  "b\0"
  "On Thu, 2018-07-19 at 12:05 -0700, Tadeusz Struk wrote:\n"
@@ -30,13 +25,13 @@
  "> > it?\n"
  "> > \n"
  "> > The reason for not doing it in the interface is that it alters the\n"
- "> > ABI.  Before this patch we had a hard packet boundary: one packet\n"
+ "> > ABI. ?Before this patch we had a hard packet boundary: one packet\n"
  "> > per read, one per write and a -EFAULT if you fail to provide a\n"
- "> > correctly sized buffer.  Now if you provide a buffer too small but\n"
+ "> > correctly sized buffer.??Now if you provide a buffer too small but\n"
  "> > don't know about the fragmentation you're going to misprocess a\n"
  "> > packet (because you think you got a whole reply but you didn't) and\n"
  "> > then you get a -EBUSY on your next command which you don't know how\n"
- "> > to handle.  The only way out is to update the applications to\n"
+ "> > to handle.??The only way out is to update the applications to\n"
  "> > handle the new behaviour, which is a no-no in Linux ABI terms.\n"
  "> \n"
  "> Don't all the existing applications that read a response in one go\n"
@@ -60,6 +55,11 @@
  "So what's wrong with fragmenting in the layer above the device driver\n"
  "(in userspace) and not actually changing the kernel?\n"
  "\n"
- James
+ "James\n"
+ "\n"
+ "--\n"
+ "To unsubscribe from this list: send the line \"unsubscribe linux-security-module\" in\n"
+ "the body of a message to majordomo at vger.kernel.org\n"
+ More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
-6f76571cf5ccd8d93ef26587d899c9a49b8685bf9ee61bb2510c2833ed1a1b5a
+97e08d0a900d2b7db6704e8a6862ce83c91afe5f768a23c77a74d3b711de3630

diff --git a/a/1.txt b/N2/1.txt
index 0e7569d..9430400 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -14,13 +14,13 @@ On Thu, 2018-07-19 at 12:05 -0700, Tadeusz Struk wrote:
 > > it?
 > > 
 > > The reason for not doing it in the interface is that it alters the
-> > ABI.  Before this patch we had a hard packet boundary: one packet
+> > ABI.  Before this patch we had a hard packet boundary: one packet
 > > per read, one per write and a -EFAULT if you fail to provide a
-> > correctly sized buffer.  Now if you provide a buffer too small but
+> > correctly sized buffer.  Now if you provide a buffer too small but
 > > don't know about the fragmentation you're going to misprocess a
 > > packet (because you think you got a whole reply but you didn't) and
 > > then you get a -EBUSY on your next command which you don't know how
-> > to handle.  The only way out is to update the applications to
+> > to handle.  The only way out is to update the applications to
 > > handle the new behaviour, which is a no-no in Linux ABI terms.
 > 
 > Don't all the existing applications that read a response in one go
diff --git a/a/content_digest b/N2/content_digest
index 5431d3a..2f81c87 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -30,13 +30,13 @@
  "> > it?\n"
  "> > \n"
  "> > The reason for not doing it in the interface is that it alters the\n"
- "> > ABI.  Before this patch we had a hard packet boundary: one packet\n"
+ "> > ABI. \302\240Before this patch we had a hard packet boundary: one packet\n"
  "> > per read, one per write and a -EFAULT if you fail to provide a\n"
- "> > correctly sized buffer.  Now if you provide a buffer too small but\n"
+ "> > correctly sized buffer.\302\240\302\240Now if you provide a buffer too small but\n"
  "> > don't know about the fragmentation you're going to misprocess a\n"
  "> > packet (because you think you got a whole reply but you didn't) and\n"
  "> > then you get a -EBUSY on your next command which you don't know how\n"
- "> > to handle.  The only way out is to update the applications to\n"
+ "> > to handle.\302\240\302\240The only way out is to update the applications to\n"
  "> > handle the new behaviour, which is a no-no in Linux ABI terms.\n"
  "> \n"
  "> Don't all the existing applications that read a response in one go\n"
@@ -62,4 +62,4 @@
  "\n"
  James
 
-6f76571cf5ccd8d93ef26587d899c9a49b8685bf9ee61bb2510c2833ed1a1b5a
+2d2061fbd3e0fd37a1782a9784a92a5c89a6a942d907e4fb0673b0d177a3ce72

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.