[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lsq.1402104389.357877816@decadent.org.uk>
Date: Sat, 07 Jun 2014 02:26:29 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC: akpm@...ux-foundation.org,
"Naoya Horiguchi" <n-horiguchi@...jp.nec.com>,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Andi Kleen" <andi@...stfloor.org>
Subject: [PATCH 3.2 86/92] mm/memory-failure.c: fix memory leak by race
between poison and unpoison
3.2.60-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
commit 3e030ecc0fc7de10fd0da10c1c19939872a31717 upstream.
When a memory error happens on an in-use page or (free and in-use)
hugepage, the victim page is isolated with its refcount set to one.
When you try to unpoison it later, unpoison_memory() calls put_page()
for it twice in order to bring the page back to free page pool (buddy or
free hugepage list). However, if another memory error occurs on the
page which we are unpoisoning, memory_failure() returns without
releasing the refcount which was incremented in the same call at first,
which results in memory leak and unconsistent num_poisoned_pages
statistics. This patch fixes it.
Signed-off-by: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
Cc: Andi Kleen <andi@...stfloor.org>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
[bwh: Backported to 3.2: s/num_poisoned_pages/bad_mce_pages/]
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
mm/memory-failure.c | 2 ++
1 file changed, 2 insertions(+)
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1094,6 +1094,8 @@ int __memory_failure(unsigned long pfn,
*/
if (!PageHWPoison(p)) {
printk(KERN_ERR "MCE %#lx: just unpoisoned\n", pfn);
+ atomic_long_sub(nr_pages, &mce_bad_pages);
+ put_page(hpage);
res = 0;
goto out;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists