Patch "hwpoison, memcg: forcibly uncharge LRU pages" has been added to the 4.9-stable tree
Subsystems (4)
This is a note to let you know that I've just added the patch titled
hwpoison, memcg: forcibly uncharge LRU pages
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
hwpoison-memcg-forcibly-uncharge-lru-pages.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
18365225f0440d09708ad9daade2ec11275c3df9Mon Sep 17 00:00:00 2001
From: Michal Hocko <[email protected]>
Date: Fri, 12 May 2017 15:46:26 -0700
Subject: hwpoison, memcg: forcibly uncharge LRU pages
From: Michal Hocko <[email protected]>
commit 18365225f0440d09708ad9daade2ec11275c3df9 upstream.
Laurent Dufour has noticed that hwpoinsoned pages are kept charged. In his particular case he has hit a bad_page("page still charged to cgroup") when onlining a hwpoison page. While this looks like something that shouldn't happen in the first place because onlining hwpages and returning them to the page allocator makes only little sense it shows a real problem.
hwpoison pages do not get freed usually so we do not uncharge them (at least not since commit 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API")). Each charge pins memcg (since e8ea14cc6ead ("mm: memcontrol:
take a css reference for each charged page")) as well and so the mem_cgroup and the associated state will never go away. Fix this leak by forcibly uncharging a LRU hwpoisoned page in delete_from_lru_cache(). We also have to tweak uncharge_list because it cannot rely on zero ref count for these pages.
--- mm/memcontrol.c | 2 +- mm/memory-failure.c | 7 +++++++ 2 files changed, 8 insertions(+), 1 deletion(-)
mm/memcontrol.c +1 -1
@@ -5531,7 +5531,7 @@ static void uncharge_list(struct list_he next = page->lru.next;VM_BUG_ON_PAGE (PageLRU (page), page); -VM_BUG_ON_PAGE (page_count (page), page); +VM_BUG_ON_PAGE (!PageHWPoison (page) &&page_count (page), page);if (!page->mem_cgroup)continue ;
mm/memory-failure.c +7 -0
@@ -535,6 +535,13 @@ static int delete_from_lru_cache(struct*/ ClearPageActive (p);ClearPageUnevictable (p); + +/* +* Poisoned page might never drop its ref count to 0 so we have +* to uncharge it manually from its memcg. +*/ +mem_cgroup_uncharge (p); +/* * drop the page count elevated by isolate_lru_page() */
Patches currently in stable-queue which might be from [email protected] are
queue-4.9/hwpoison-memcg-forcibly-uncharge-lru-pages.patch queue-4.9/mm-mmap.c-do-not-blow-on-prot_none-map_fixed-holes-in-the-stack.patch