mm/memory-failure.c: fix memory leak by race between poison and unpoison

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@ah.jp.nec.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: <stable@vger.kernel.org>    [2.6.32+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index dbf8922216ade6c88bbf1855cca60e881abc6b47..9ccef39a9de261c96f4e5775d7dca48b63d4d133 100644 (file)
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1153,6 +1153,8 @@ int memory_failure(unsigned long pfn, int trapno, int flags)
         */
        if (!PageHWPoison(p)) {
                printk(KERN_ERR "MCE %#lx: just unpoisoned\n", pfn);
+               atomic_long_sub(nr_pages, &num_poisoned_pages);
+               put_page(hpage);
                res = 0;
                goto out;
        }