This is a note to let you know that I've just added the patch titled
mm: fix process accidentally killed by mce because of huge page migration
to the 3.10-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:
mm-fix-process-accidentally-killed-by-mce-because-of-huge-page-migration.patch
and it can be found in the queue-3.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From [email protected] Tue Feb 18 14:12:39 2014
From: Xishi Qiu <[email protected]>
Date: Fri, 14 Feb 2014 10:33:35 +0800
Subject: mm: fix process accidentally killed by mce because of huge page
migration
To: Naoya Horiguchi <[email protected]>, Greg Kroah-Hartman
<[email protected]>
Cc: <[email protected]>, <[email protected]>, Linux MM
<[email protected]>, <[email protected]>, Xishi Qiu
<[email protected]>, Li Zefan <[email protected]>, Andrew Morton
<[email protected]>
Message-ID: <[email protected]>
From: Xishi Qiu <[email protected]>
Based on c8721bbbdd36382de51cd6b7a56322e0acca2414 upstream, but only the
bugfix portion pulled out.
Hi Naoya or Greg,
We found a bug in 3.10.x.
The problem is that we accidentally have a hwpoisoned hugepage in free
hugepage list. It could happend in the the following scenario:
process A process B
migrate_huge_page
put_page (old hugepage)
linked to free hugepage list
hugetlb_fault
hugetlb_no_page
alloc_huge_page
dequeue_huge_page_vma
dequeue_huge_page_node
(steal hwpoisoned hugepage)
set_page_hwpoison_huge_page
dequeue_hwpoisoned_huge_page
(fail to dequeue)
I tested this bug, one process keeps allocating huge page, and I
use sysfs interface to soft offline a huge page, then received:
"MCE: Killing UCP:2717 due to hardware memory corruption fault at 8200034"
Upstream kernel is free from this bug because of these two commits:
f15bdfa802bfa5eb6b4b5a241b97ec9fa1204a35
mm/memory-failure.c: fix memory leak in successful soft offlining
c8721bbbdd36382de51cd6b7a56322e0acca2414
mm: memory-hotplug: enable memory hotplug to handle hugepage
The first one, although the problem is about memory leak, this patch
moves unset_migratetype_isolate(), which is important to avoid the race.
The latter is not a bug fix and it's too big, so I rewrite a small one.
The following patch can fix this bug.(please apply f15bdfa802bf first)
Signed-off-by: Xishi Qiu <[email protected]>
Reviewed-by: Naoya Horiguchi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/hugetlb.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -21,6 +21,7 @@
#include <linux/rmap.h>
#include <linux/swap.h>
#include <linux/swapops.h>
+#include <linux/page-isolation.h>
#include <asm/page.h>
#include <asm/pgtable.h>
@@ -517,9 +518,15 @@ static struct page *dequeue_huge_page_no
{
struct page *page;
- if (list_empty(&h->hugepage_freelists[nid]))
+ list_for_each_entry(page, &h->hugepage_freelists[nid], lru)
+ if (!is_migrate_isolate_page(page))
+ break;
+ /*
+ * if 'non-isolated free hugepage' not found on the list,
+ * the allocation fails.
+ */
+ if (&h->hugepage_freelists[nid] == &page->lru)
return NULL;
- page = list_entry(h->hugepage_freelists[nid].next, struct page, lru);
list_move(&page->lru, &h->hugepage_activelist);
set_page_refcounted(page);
h->free_huge_pages--;
Patches currently in stable-queue which might be from [email protected] are
queue-3.10/mm-memory-failure.c-fix-memory-leak-in-successful-soft-offlining.patch
queue-3.10/mm-fix-process-accidentally-killed-by-mce-because-of-huge-page-migration.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
