All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <4F5F847C.3060505@parallels.com>

diff --git a/a/1.txt b/N1/1.txt
index bbfb6a6..a7b839a 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,5 +1,5 @@
 On 03/13/2012 09:00 PM, Greg Thelen wrote:
-> Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>  writes:
+> Glauber Costa<glommer@parallels.com>  writes:
 >> 2) For the kernel itself, we are mostly concerned that a malicious container may
 >> pin into memory big amounts of kernel memory which is, ultimately,
 >> unreclaimable. In particular, with overcommit allowed scenarios, you can fill
@@ -17,3 +17,10 @@ happens first. And we don't have that option with pinned kernel memory.
 Of course you *can* run your system without swap, but the whole thing 
 exists exactly because there is a large enough # of ppl who wants to be 
 able to overcommit their physical memory, without failing allocations.
+
+--
+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/ .
+Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
+Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
diff --git a/a/content_digest b/N1/content_digest
index c822141..2eed008 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -4,32 +4,31 @@
  "ref\020120313152446.28b0d696.kamezawa.hiroyu@jp.fujitsu.com\0"
  "ref\04F5F236A.1070609@parallels.com\0"
  "ref\0xr93d38g77w5.fsf@gthelen.mtv.corp.google.com\0"
- "ref\0xr93d38g77w5.fsf-aSPv4SP+Du0KgorLzL7FmE7CuiCeIGUxQQ4Iyu8u01E@public.gmane.org\0"
- "From\0Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>\0"
+ "From\0Glauber Costa <glommer@parallels.com>\0"
  "Subject\0Re: [PATCH v2 02/13] memcg: Kernel memory accounting infrastructure.\0"
  "Date\0Tue, 13 Mar 2012 21:31:40 +0400\0"
- "To\0Greg Thelen <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>\0"
- "Cc\0KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>"
-  Suleiman Souhlal <ssouhlal-HZy0K5TPuP5AfugRpC6u6w@public.gmane.org>
-  cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  suleiman-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
-  penberg-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
-  cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org
-  yinghan-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
-  hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
-  peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org
-  dan.magenheimer-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org
-  hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org
-  mgorman-l3A5Bk7waGM@public.gmane.org
-  James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org
-  linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
-  devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
-  linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
- " rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org\0"
+ "To\0Greg Thelen <gthelen@google.com>\0"
+ "Cc\0KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>"
+  Suleiman Souhlal <ssouhlal@freebsd.org>
+  cgroups@vger.kernel.org
+  suleiman@google.com
+  penberg@kernel.org
+  cl@linux.com
+  yinghan@google.com
+  hughd@google.com
+  peterz@infradead.org
+  dan.magenheimer@oracle.com
+  hannes@cmpxchg.org
+  mgorman@suse.de
+  James.Bottomley@hansenpartnership.com
+  linux-mm@kvack.org
+  devel@openvz.org
+  linux-kernel@vger.kernel.org
+ " rientjes@google.com\0"
  "\00:1\0"
  "b\0"
  "On 03/13/2012 09:00 PM, Greg Thelen wrote:\n"
- "> Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>  writes:\n"
+ "> Glauber Costa<glommer@parallels.com>  writes:\n"
  ">> 2) For the kernel itself, we are mostly concerned that a malicious container may\n"
  ">> pin into memory big amounts of kernel memory which is, ultimately,\n"
  ">> unreclaimable. In particular, with overcommit allowed scenarios, you can fill\n"
@@ -46,6 +45,13 @@
  "\n"
  "Of course you *can* run your system without swap, but the whole thing \n"
  "exists exactly because there is a large enough # of ppl who wants to be \n"
- able to overcommit their physical memory, without failing allocations.
+ "able to overcommit their physical memory, without failing allocations.\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"
+ "Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/\n"
+ "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>"
 
-42dbec6a76a4af1935a3cbeab039b4c54b466680220782c6f8e9d7e40f584448
+708934cd89a641c50b216d4da1e3bc9950818c0038741cdf246777a93256f3df

diff --git a/a/1.txt b/N2/1.txt
index bbfb6a6..b0d3f68 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -1,5 +1,5 @@
 On 03/13/2012 09:00 PM, Greg Thelen wrote:
-> Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>  writes:
+> Glauber Costa<glommer@parallels.com>  writes:
 >> 2) For the kernel itself, we are mostly concerned that a malicious container may
 >> pin into memory big amounts of kernel memory which is, ultimately,
 >> unreclaimable. In particular, with overcommit allowed scenarios, you can fill
diff --git a/a/content_digest b/N2/content_digest
index c822141..8b57a6c 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -4,32 +4,31 @@
  "ref\020120313152446.28b0d696.kamezawa.hiroyu@jp.fujitsu.com\0"
  "ref\04F5F236A.1070609@parallels.com\0"
  "ref\0xr93d38g77w5.fsf@gthelen.mtv.corp.google.com\0"
- "ref\0xr93d38g77w5.fsf-aSPv4SP+Du0KgorLzL7FmE7CuiCeIGUxQQ4Iyu8u01E@public.gmane.org\0"
- "From\0Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>\0"
+ "From\0Glauber Costa <glommer@parallels.com>\0"
  "Subject\0Re: [PATCH v2 02/13] memcg: Kernel memory accounting infrastructure.\0"
  "Date\0Tue, 13 Mar 2012 21:31:40 +0400\0"
- "To\0Greg Thelen <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>\0"
- "Cc\0KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>"
-  Suleiman Souhlal <ssouhlal-HZy0K5TPuP5AfugRpC6u6w@public.gmane.org>
-  cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  suleiman-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
-  penberg-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
-  cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org
-  yinghan-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
-  hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
-  peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org
-  dan.magenheimer-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org
-  hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org
-  mgorman-l3A5Bk7waGM@public.gmane.org
-  James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org
-  linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
-  devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
-  linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
- " rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org\0"
+ "To\0Greg Thelen <gthelen@google.com>\0"
+ "Cc\0KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>"
+  Suleiman Souhlal <ssouhlal@freebsd.org>
+  <cgroups@vger.kernel.org>
+  <suleiman@google.com>
+  <penberg@kernel.org>
+  <cl@linux.com>
+  <yinghan@google.com>
+  <hughd@google.com>
+  <peterz@infradead.org>
+  <dan.magenheimer@oracle.com>
+  <hannes@cmpxchg.org>
+  <mgorman@suse.de>
+  <James.Bottomley@hansenpartnership.com>
+  <linux-mm@kvack.org>
+  <devel@openvz.org>
+  <linux-kernel@vger.kernel.org>
+ " <rientjes@google.com>\0"
  "\00:1\0"
  "b\0"
  "On 03/13/2012 09:00 PM, Greg Thelen wrote:\n"
- "> Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>  writes:\n"
+ "> Glauber Costa<glommer@parallels.com>  writes:\n"
  ">> 2) For the kernel itself, we are mostly concerned that a malicious container may\n"
  ">> pin into memory big amounts of kernel memory which is, ultimately,\n"
  ">> unreclaimable. In particular, with overcommit allowed scenarios, you can fill\n"
@@ -48,4 +47,4 @@
  "exists exactly because there is a large enough # of ppl who wants to be \n"
  able to overcommit their physical memory, without failing allocations.
 
-42dbec6a76a4af1935a3cbeab039b4c54b466680220782c6f8e9d7e40f584448
+ea686647d0f8045fcb1f055cbcfc7e3fb47debd3c90e884441c93ee42c7dbf4b

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.