All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <5A3DEA6A.9080709@huawei.com>

diff --git a/a/1.txt b/N1/1.txt
index b77c1c6..89d4881 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -14,7 +14,7 @@ On 2017/12/21 16:55, Xishi Qiu wrote:
 > .
 > 
 
-Hi, here is another question from lious.lilei at hisilicon.com
+Hi, here is another question from lious.lilei@hisilicon.com
 
 
 As ARM-ARM said
@@ -116,3 +116,13 @@ So I have two questions for this scene.
 1. When the same virtual address allocated from ioremap, first is 4K size, second is 2M size, if Kernel would leak memory.
 
 2. Kernel modifies the old invalid 4K pagetable to 2M, but doesn`t follow the ARM break-before-make flow, CPU maybe get the old invalid 4K pagetable information, then Kernel would panic.
+
+ 
+
+
+
+--
+To unsubscribe, send a message with 'unsubscribe linux-mm' in
+the body to majordomo@kvack.org.  For more info on Linux MM,
+see: http://www.linux-mm.org/ .
+Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
diff --git a/a/content_digest b/N1/content_digest
index 1c8d0df..7982fa7 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,8 +1,17 @@
  "ref\05A3B76EE.8020001@huawei.com\0"
- "From\0qiuxishi@huawei.com (Xishi Qiu)\0"
- "Subject\0[RFC] does ioremap() cause memory leak?\0"
+ "From\0Xishi Qiu <qiuxishi@huawei.com>\0"
+ "Subject\0Re: [RFC] does ioremap() cause memory leak?\0"
  "Date\0Sat, 23 Dec 2017 13:32:26 +0800\0"
- "To\0linux-arm-kernel@lists.infradead.org\0"
+ "To\0Xishi Qiu <qiuxishi@huawei.com>\0"
+ "Cc\0Toshi Kani <toshi.kani@hp.com>"
+  H. Peter Anvin <hpa@zytor.com>
+  Thomas Gleixner <tglx@linutronix.de>
+  Ingo Molnar <mingo@redhat.com>
+  LKML <linux-kernel@vger.kernel.org>
+  Linux MM <linux-mm@kvack.org>
+  lious.lilei@hisilicon.com
+  linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>
+ " LinuxArm <linuxarm@huawei.com>\0"
  "\00:1\0"
  "b\0"
  "On 2017/12/21 16:55, Xishi Qiu wrote:\n"
@@ -21,7 +30,7 @@
  "> .\n"
  "> \n"
  "\n"
- "Hi, here is another question from lious.lilei at hisilicon.com\n"
+ "Hi, here is another question from lious.lilei@hisilicon.com\n"
  "\n"
  "\n"
  "As ARM-ARM said\n"
@@ -122,6 +131,16 @@
  "\n"
  "1. When the same virtual address allocated from ioremap, first is 4K size, second is 2M size, if Kernel would leak memory.\n"
  "\n"
- 2. Kernel modifies the old invalid 4K pagetable to 2M, but doesn`t follow the ARM break-before-make flow, CPU maybe get the old invalid 4K pagetable information, then Kernel would panic.
+ "2. Kernel modifies the old invalid 4K pagetable to 2M, but doesn`t follow the ARM break-before-make flow, CPU maybe get the old invalid 4K pagetable information, then Kernel would panic.\n"
+ "\n"
+ " \n"
+ "\n"
+ "\n"
+ "\n"
+ "--\n"
+ "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n"
+ "the body to majordomo@kvack.org.  For more info on Linux MM,\n"
+ "see: http://www.linux-mm.org/ .\n"
+ "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>"
 
-353b15a52d9dd17195ad84cca824a98b6f3f90bac74091ea75fdcdef13c0a81e
+00f987c223b9934b5f82f07af2bb78775c4dd258e2ce15f0905f9d8f27a99e8c

diff --git a/a/1.txt b/N2/1.txt
index b77c1c6..4f38f52 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -14,22 +14,22 @@ On 2017/12/21 16:55, Xishi Qiu wrote:
 > .
 > 
 
-Hi, here is another question from lious.lilei at hisilicon.com
+Hi, here is another question from lious.lilei@hisilicon.com
 
 
 As ARM-ARM said
 
-?The architecture permits the caching of any translation table entry that has been returned from memory without a
+“The architecture permits the caching of any translation table entry that has been returned from memory without a
 
 fault, provided that the entry does not, itself, cause a Translation fault, an Address size fault, or an Access Flag fault.
 
 This means that the entries that can be cached include:
 
-? Entries in translation tables that point to subsequent tables to be used in that stage of translation.
+• Entries in translation tables that point to subsequent tables to be used in that stage of translation.
 
-? Stage 2 translation table entries used as part of a stage 1 translation table walk
+• Stage 2 translation table entries used as part of a stage 1 translation table walk
 
-? Stage 2 translation table entries used to translate the output address of the stage 1 translation.?
+• Stage 2 translation table entries used to translate the output address of the stage 1 translation.”
 
  
 
diff --git a/a/content_digest b/N2/content_digest
index 1c8d0df..e129791 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -1,8 +1,17 @@
  "ref\05A3B76EE.8020001@huawei.com\0"
- "From\0qiuxishi@huawei.com (Xishi Qiu)\0"
- "Subject\0[RFC] does ioremap() cause memory leak?\0"
+ "From\0Xishi Qiu <qiuxishi@huawei.com>\0"
+ "Subject\0Re: [RFC] does ioremap() cause memory leak?\0"
  "Date\0Sat, 23 Dec 2017 13:32:26 +0800\0"
- "To\0linux-arm-kernel@lists.infradead.org\0"
+ "To\0Xishi Qiu <qiuxishi@huawei.com>\0"
+ "Cc\0Toshi Kani <toshi.kani@hp.com>"
+  H. Peter Anvin <hpa@zytor.com>
+  Thomas Gleixner <tglx@linutronix.de>
+  Ingo Molnar <mingo@redhat.com>
+  LKML <linux-kernel@vger.kernel.org>
+  Linux MM <linux-mm@kvack.org>
+  <lious.lilei@hisilicon.com>
+  linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>
+ " LinuxArm <linuxarm@huawei.com>\0"
  "\00:1\0"
  "b\0"
  "On 2017/12/21 16:55, Xishi Qiu wrote:\n"
@@ -21,22 +30,22 @@
  "> .\n"
  "> \n"
  "\n"
- "Hi, here is another question from lious.lilei at hisilicon.com\n"
+ "Hi, here is another question from lious.lilei@hisilicon.com\n"
  "\n"
  "\n"
  "As ARM-ARM said\n"
  "\n"
- "?The architecture permits the caching of any translation table entry that has been returned from memory without a\n"
+ "\342\200\234The architecture permits the caching of any translation table entry that has been returned from memory without a\n"
  "\n"
  "fault, provided that the entry does not, itself, cause a Translation fault, an Address size fault, or an Access Flag fault.\n"
  "\n"
  "This means that the entries that can be cached include:\n"
  "\n"
- "? Entries in translation tables that point to subsequent tables to be used in that stage of translation.\n"
+ "\342\200\242 Entries in translation tables that point to subsequent tables to be used in that stage of translation.\n"
  "\n"
- "? Stage 2 translation table entries used as part of a stage 1 translation table walk\n"
+ "\342\200\242 Stage 2 translation table entries used as part of a stage 1 translation table walk\n"
  "\n"
- "? Stage 2 translation table entries used to translate the output address of the stage 1 translation.?\n"
+ "\342\200\242 Stage 2 translation table entries used to translate the output address of the stage 1 translation.\342\200\235\n"
  "\n"
  " \n"
  "\n"
@@ -124,4 +133,4 @@
  "\n"
  2. Kernel modifies the old invalid 4K pagetable to 2M, but doesn`t follow the ARM break-before-make flow, CPU maybe get the old invalid 4K pagetable information, then Kernel would panic.
 
-353b15a52d9dd17195ad84cca824a98b6f3f90bac74091ea75fdcdef13c0a81e
+260c297aaf0e106f4748e93fc20b2284a00254342ac2dc4eab9d238f1d5c4b13

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.