All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20110128084121.GE2213@cmpxchg.org>

diff --git a/a/1.txt b/N1/1.txt
index 09f6b77..f84d618 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -27,18 +27,18 @@ On Fri, Jan 28, 2011 at 05:25:58PM +0900, Minchan Kim wrote:
 > >> reclaiming and loop forever by below part.
 > >>
 > >> @@ -1854,9 +1858,6 @@ static int __mem_cgroup_do_charge(struct
-> >>       } else
-> >>               mem_over_limit = mem_cgroup_from_res_counter(fail_res, res);
+> >>       } else
+> >>               mem_over_limit = mem_cgroup_from_res_counter(fail_res, res);
 > >>
-> >> -     if (csize > PAGE_SIZE) /* change csize and retry */
-> >> -             return CHARGE_RETRY;
+> >> -     if (csize > PAGE_SIZE) /* change csize and retry */
+> >> -             return CHARGE_RETRY;
 > >> -
-> >>       if (!(gfp_mask & __GFP_WAIT))
-> >>               return CHARGE_WOULDBLOCK;
+> >>       if (!(gfp_mask & __GFP_WAIT))
+> >>               return CHARGE_WOULDBLOCK;
 > >>
 > >> Am I missing something?
 > >
-> > No, you are correct.  But I am not sure the order really matters in
+> > No, you are correct.  But I am not sure the order really matters in
 > > theory: you have two endless loops that need independent fixing.
 > 
 > That's why I ask a question.
@@ -59,3 +59,10 @@ Currently, this code is never reached due to the endless loop you
 already spotted.
 
 HTH
+
+--
+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 policy in Canada: sign http://dissolvethecrtc.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 595f418..680ba7e 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -45,18 +45,18 @@
  "> >> reclaiming and loop forever by below part.\n"
  "> >>\n"
  "> >> @@ -1854,9 +1858,6 @@ static int __mem_cgroup_do_charge(struct\n"
- "> >> \302\240 \302\240 \302\240 } else\n"
- "> >> \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 mem_over_limit = mem_cgroup_from_res_counter(fail_res, res);\n"
+ "> >>       } else\n"
+ "> >>               mem_over_limit = mem_cgroup_from_res_counter(fail_res, res);\n"
  "> >>\n"
- "> >> - \302\240 \302\240 if (csize > PAGE_SIZE) /* change csize and retry */\n"
- "> >> - \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 return CHARGE_RETRY;\n"
+ "> >> -     if (csize > PAGE_SIZE) /* change csize and retry */\n"
+ "> >> -             return CHARGE_RETRY;\n"
  "> >> -\n"
- "> >> \302\240 \302\240 \302\240 if (!(gfp_mask & __GFP_WAIT))\n"
- "> >> \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 return CHARGE_WOULDBLOCK;\n"
+ "> >>       if (!(gfp_mask & __GFP_WAIT))\n"
+ "> >>               return CHARGE_WOULDBLOCK;\n"
  "> >>\n"
  "> >> Am I missing something?\n"
  "> >\n"
- "> > No, you are correct. \302\240But I am not sure the order really matters in\n"
+ "> > No, you are correct.  But I am not sure the order really matters in\n"
  "> > theory: you have two endless loops that need independent fixing.\n"
  "> \n"
  "> That's why I ask a question.\n"
@@ -76,6 +76,13 @@
  "Currently, this code is never reached due to the endless loop you\n"
  "already spotted.\n"
  "\n"
- HTH
+ "HTH\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 policy in Canada: sign http://dissolvethecrtc.ca/\n"
+ "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>"
 
-94db6bf8a73171ba9185be8c70776e68a947aa2bb402bd12dfc726e4f908fc68
+48f60dd6651f5958f1dff3e2f109f0e801fc89e3b20409f21772adce7d4cafe0

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.