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

diff --git a/a/1.txt b/N1/1.txt
index a1666c4..00aad41 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -9,107 +9,3 @@ Thank you.
 
 Okay, fair enough. I also added why we prefer temporarily breaching
 the limit over failing the allocation. How is this?
-
-From 9034d2e6a21036774df9a8e021511720cf432c82 Mon Sep 17 00:00:00 2001
-From: Johannes Weiner <hannes@cmpxchg.org>
-Date: Mon, 24 Oct 2016 16:01:55 -0400
-Subject: [PATCH] mm: memcontrol: do not recurse in direct reclaim
-
-On 4.0, we saw a stack corruption from a page fault entering direct
-memory cgroup reclaim, calling into btrfs_releasepage(), which then
-tried to allocate an extent and recursed back into a kmem charge ad
-nauseam:
-
-[...]
-[<ffffffff8136590c>] btrfs_releasepage+0x2c/0x30
-[<ffffffff811559a2>] try_to_release_page+0x32/0x50
-[<ffffffff81168cea>] shrink_page_list+0x6da/0x7a0
-[<ffffffff811693b5>] shrink_inactive_list+0x1e5/0x510
-[<ffffffff8116a0a5>] shrink_lruvec+0x605/0x7f0
-[<ffffffff8116a37e>] shrink_zone+0xee/0x320
-[<ffffffff8116a934>] do_try_to_free_pages+0x174/0x440
-[<ffffffff8116adf7>] try_to_free_mem_cgroup_pages+0xa7/0x130
-[<ffffffff811b738b>] try_charge+0x17b/0x830
-[<ffffffff811bb5b0>] memcg_charge_kmem+0x40/0x80
-[<ffffffff811a96a9>] new_slab+0x2d9/0x5a0
-[<ffffffff817b2547>] __slab_alloc+0x2fd/0x44f
-[<ffffffff811a9b03>] kmem_cache_alloc+0x193/0x1e0
-[<ffffffff813801e1>] alloc_extent_state+0x21/0xc0
-[<ffffffff813820c5>] __clear_extent_bit+0x2b5/0x400
-[<ffffffff81386d03>] try_release_extent_mapping+0x1a3/0x220
-[<ffffffff813658a1>] __btrfs_releasepage+0x31/0x70
-[<ffffffff8136590c>] btrfs_releasepage+0x2c/0x30
-[<ffffffff811559a2>] try_to_release_page+0x32/0x50
-[<ffffffff81168cea>] shrink_page_list+0x6da/0x7a0
-[<ffffffff811693b5>] shrink_inactive_list+0x1e5/0x510
-[<ffffffff8116a0a5>] shrink_lruvec+0x605/0x7f0
-[<ffffffff8116a37e>] shrink_zone+0xee/0x320
-[<ffffffff8116a934>] do_try_to_free_pages+0x174/0x440
-[<ffffffff8116adf7>] try_to_free_mem_cgroup_pages+0xa7/0x130
-[<ffffffff811b738b>] try_charge+0x17b/0x830
-[<ffffffff811bbfd5>] mem_cgroup_try_charge+0x65/0x1c0
-[<ffffffff8118338f>] handle_mm_fault+0x117f/0x1510
-[<ffffffff81041cf7>] __do_page_fault+0x177/0x420
-[<ffffffff81041fac>] do_page_fault+0xc/0x10
-[<ffffffff817c0182>] page_fault+0x22/0x30
-
-On later kernels, kmem charging is opt-in rather than opt-out, and
-that particular kmem allocation in btrfs_releasepage() is no longer
-being charged and won't recurse and overrun the stack anymore. But
-it's not impossible for an accounted allocation to happen from the
-memcg direct reclaim context, and we needed to reproduce this crash
-many times before we even got a useful stack trace out of it.
-
-Like other direct reclaimers, mark tasks in memcg reclaim PF_MEMALLOC
-to avoid recursing into any other form of direct reclaim. Then let
-recursive charges from PF_MEMALLOC contexts bypass the cgroup limit.
-
-Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
-Acked-by: Michal Hocko <mhocko@suse.com>
----
- mm/memcontrol.c | 9 +++++++++
- mm/vmscan.c     | 2 ++
- 2 files changed, 11 insertions(+)
-
-diff --git a/mm/memcontrol.c b/mm/memcontrol.c
-index ae052b5e3315..0f870ba43942 100644
---- a/mm/memcontrol.c
-+++ b/mm/memcontrol.c
-@@ -1917,6 +1917,15 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
- 		     current->flags & PF_EXITING))
- 		goto force;
- 
-+	/*
-+	 * Prevent unbounded recursion when reclaim operations need to
-+	 * allocate memory. This might exceed the limits temporarily,
-+	 * but we prefer facilitating memory reclaim and getting back
-+	 * under the limit over triggering OOM kills in these cases.
-+	 */
-+	if (unlikely(current->flags & PF_MEMALLOC))
-+		goto force;
-+
- 	if (unlikely(task_in_memcg_oom(current)))
- 		goto nomem;
- 
-diff --git a/mm/vmscan.c b/mm/vmscan.c
-index 744f926af442..76fda2268148 100644
---- a/mm/vmscan.c
-+++ b/mm/vmscan.c
-@@ -3043,7 +3043,9 @@ unsigned long try_to_free_mem_cgroup_pages(struct mem_cgroup *memcg,
- 					    sc.gfp_mask,
- 					    sc.reclaim_idx);
- 
-+	current->flags |= PF_MEMALLOC;
- 	nr_reclaimed = do_try_to_free_pages(zonelist, &sc);
-+	current->flags &= ~PF_MEMALLOC;
- 
- 	trace_mm_vmscan_memcg_reclaim_end(nr_reclaimed);
- 
--- 
-2.10.0
-
---
-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 d73c15d..e03f861 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -23,110 +23,6 @@
  "> reclaim due to stack overflows.\n"
  "\n"
  "Okay, fair enough. I also added why we prefer temporarily breaching\n"
- "the limit over failing the allocation. How is this?\n"
- "\n"
- "From 9034d2e6a21036774df9a8e021511720cf432c82 Mon Sep 17 00:00:00 2001\n"
- "From: Johannes Weiner <hannes@cmpxchg.org>\n"
- "Date: Mon, 24 Oct 2016 16:01:55 -0400\n"
- "Subject: [PATCH] mm: memcontrol: do not recurse in direct reclaim\n"
- "\n"
- "On 4.0, we saw a stack corruption from a page fault entering direct\n"
- "memory cgroup reclaim, calling into btrfs_releasepage(), which then\n"
- "tried to allocate an extent and recursed back into a kmem charge ad\n"
- "nauseam:\n"
- "\n"
- "[...]\n"
- "[<ffffffff8136590c>] btrfs_releasepage+0x2c/0x30\n"
- "[<ffffffff811559a2>] try_to_release_page+0x32/0x50\n"
- "[<ffffffff81168cea>] shrink_page_list+0x6da/0x7a0\n"
- "[<ffffffff811693b5>] shrink_inactive_list+0x1e5/0x510\n"
- "[<ffffffff8116a0a5>] shrink_lruvec+0x605/0x7f0\n"
- "[<ffffffff8116a37e>] shrink_zone+0xee/0x320\n"
- "[<ffffffff8116a934>] do_try_to_free_pages+0x174/0x440\n"
- "[<ffffffff8116adf7>] try_to_free_mem_cgroup_pages+0xa7/0x130\n"
- "[<ffffffff811b738b>] try_charge+0x17b/0x830\n"
- "[<ffffffff811bb5b0>] memcg_charge_kmem+0x40/0x80\n"
- "[<ffffffff811a96a9>] new_slab+0x2d9/0x5a0\n"
- "[<ffffffff817b2547>] __slab_alloc+0x2fd/0x44f\n"
- "[<ffffffff811a9b03>] kmem_cache_alloc+0x193/0x1e0\n"
- "[<ffffffff813801e1>] alloc_extent_state+0x21/0xc0\n"
- "[<ffffffff813820c5>] __clear_extent_bit+0x2b5/0x400\n"
- "[<ffffffff81386d03>] try_release_extent_mapping+0x1a3/0x220\n"
- "[<ffffffff813658a1>] __btrfs_releasepage+0x31/0x70\n"
- "[<ffffffff8136590c>] btrfs_releasepage+0x2c/0x30\n"
- "[<ffffffff811559a2>] try_to_release_page+0x32/0x50\n"
- "[<ffffffff81168cea>] shrink_page_list+0x6da/0x7a0\n"
- "[<ffffffff811693b5>] shrink_inactive_list+0x1e5/0x510\n"
- "[<ffffffff8116a0a5>] shrink_lruvec+0x605/0x7f0\n"
- "[<ffffffff8116a37e>] shrink_zone+0xee/0x320\n"
- "[<ffffffff8116a934>] do_try_to_free_pages+0x174/0x440\n"
- "[<ffffffff8116adf7>] try_to_free_mem_cgroup_pages+0xa7/0x130\n"
- "[<ffffffff811b738b>] try_charge+0x17b/0x830\n"
- "[<ffffffff811bbfd5>] mem_cgroup_try_charge+0x65/0x1c0\n"
- "[<ffffffff8118338f>] handle_mm_fault+0x117f/0x1510\n"
- "[<ffffffff81041cf7>] __do_page_fault+0x177/0x420\n"
- "[<ffffffff81041fac>] do_page_fault+0xc/0x10\n"
- "[<ffffffff817c0182>] page_fault+0x22/0x30\n"
- "\n"
- "On later kernels, kmem charging is opt-in rather than opt-out, and\n"
- "that particular kmem allocation in btrfs_releasepage() is no longer\n"
- "being charged and won't recurse and overrun the stack anymore. But\n"
- "it's not impossible for an accounted allocation to happen from the\n"
- "memcg direct reclaim context, and we needed to reproduce this crash\n"
- "many times before we even got a useful stack trace out of it.\n"
- "\n"
- "Like other direct reclaimers, mark tasks in memcg reclaim PF_MEMALLOC\n"
- "to avoid recursing into any other form of direct reclaim. Then let\n"
- "recursive charges from PF_MEMALLOC contexts bypass the cgroup limit.\n"
- "\n"
- "Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>\n"
- "Acked-by: Michal Hocko <mhocko@suse.com>\n"
- "---\n"
- " mm/memcontrol.c | 9 +++++++++\n"
- " mm/vmscan.c     | 2 ++\n"
- " 2 files changed, 11 insertions(+)\n"
- "\n"
- "diff --git a/mm/memcontrol.c b/mm/memcontrol.c\n"
- "index ae052b5e3315..0f870ba43942 100644\n"
- "--- a/mm/memcontrol.c\n"
- "+++ b/mm/memcontrol.c\n"
- "@@ -1917,6 +1917,15 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,\n"
- " \t\t     current->flags & PF_EXITING))\n"
- " \t\tgoto force;\n"
- " \n"
- "+\t/*\n"
- "+\t * Prevent unbounded recursion when reclaim operations need to\n"
- "+\t * allocate memory. This might exceed the limits temporarily,\n"
- "+\t * but we prefer facilitating memory reclaim and getting back\n"
- "+\t * under the limit over triggering OOM kills in these cases.\n"
- "+\t */\n"
- "+\tif (unlikely(current->flags & PF_MEMALLOC))\n"
- "+\t\tgoto force;\n"
- "+\n"
- " \tif (unlikely(task_in_memcg_oom(current)))\n"
- " \t\tgoto nomem;\n"
- " \n"
- "diff --git a/mm/vmscan.c b/mm/vmscan.c\n"
- "index 744f926af442..76fda2268148 100644\n"
- "--- a/mm/vmscan.c\n"
- "+++ b/mm/vmscan.c\n"
- "@@ -3043,7 +3043,9 @@ unsigned long try_to_free_mem_cgroup_pages(struct mem_cgroup *memcg,\n"
- " \t\t\t\t\t    sc.gfp_mask,\n"
- " \t\t\t\t\t    sc.reclaim_idx);\n"
- " \n"
- "+\tcurrent->flags |= PF_MEMALLOC;\n"
- " \tnr_reclaimed = do_try_to_free_pages(zonelist, &sc);\n"
- "+\tcurrent->flags &= ~PF_MEMALLOC;\n"
- " \n"
- " \ttrace_mm_vmscan_memcg_reclaim_end(nr_reclaimed);\n"
- " \n"
- "-- \n"
- "2.10.0\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>"
+ the limit over failing the allocation. How is this?
 
-6c1f23dd3d2d1600a5e90efa6cc05ad20a1092263ffcbb47d62aab46f7a5b404
+12d22c2e7c0948e509ae753362467c0d056cf3bb7c931f755851319a35feb63a

diff --git a/a/1.txt b/N2/1.txt
index a1666c4..9759ab3 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -10,7 +10,7 @@ Thank you.
 Okay, fair enough. I also added why we prefer temporarily breaching
 the limit over failing the allocation. How is this?
 
-From 9034d2e6a21036774df9a8e021511720cf432c82 Mon Sep 17 00:00:00 2001
+>From 9034d2e6a21036774df9a8e021511720cf432c82 Mon Sep 17 00:00:00 2001
 From: Johannes Weiner <hannes@cmpxchg.org>
 Date: Mon, 24 Oct 2016 16:01:55 -0400
 Subject: [PATCH] mm: memcontrol: do not recurse in direct reclaim
@@ -107,9 +107,3 @@ index 744f926af442..76fda2268148 100644
  
 -- 
 2.10.0
-
---
-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/N2/content_digest
index d73c15d..37cca2d 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -25,7 +25,7 @@
  "Okay, fair enough. I also added why we prefer temporarily breaching\n"
  "the limit over failing the allocation. How is this?\n"
  "\n"
- "From 9034d2e6a21036774df9a8e021511720cf432c82 Mon Sep 17 00:00:00 2001\n"
+ ">From 9034d2e6a21036774df9a8e021511720cf432c82 Mon Sep 17 00:00:00 2001\n"
  "From: Johannes Weiner <hannes@cmpxchg.org>\n"
  "Date: Mon, 24 Oct 2016 16:01:55 -0400\n"
  "Subject: [PATCH] mm: memcontrol: do not recurse in direct reclaim\n"
@@ -121,12 +121,6 @@
  " \ttrace_mm_vmscan_memcg_reclaim_end(nr_reclaimed);\n"
  " \n"
  "-- \n"
- "2.10.0\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>"
+ 2.10.0
 
-6c1f23dd3d2d1600a5e90efa6cc05ad20a1092263ffcbb47d62aab46f7a5b404
+f52fc1d5ffb450577817d1dd60f44c3f55dccc73ac8f3211078c2ba2a47cc1b6

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.