Patch "mm, page_alloc: keep pcp count and list contents in sync if struct page is corrupted" has been added to the 4.9-stable tree
Subsystems (3)
This is a note to let you know that I've just added the patch titled
mm, page_alloc: keep pcp count and list contents in sync if struct page is corrupted
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:
mm-page_alloc-keep-pcp-count-and-list-contents-in-sync-if-struct-page-is-corrupted.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
a6de734bc002fe2027ccc074fbbd87d72957b7a4Mon Sep 17 00:00:00 2001
From: Mel Gorman <[email protected]>
Date: Mon, 12 Dec 2016 16:44:41 -0800
Subject: mm, page_alloc: keep pcp count and list contents in sync if struct page is corrupted
From: Mel Gorman <[email protected]>
commit a6de734bc002fe2027ccc074fbbd87d72957b7a4 upstream.
Vlastimil Babka pointed out that commit 479f854a207c ("mm, page_alloc:
defer debugging checks of pages allocated from the PCP") will allow the per-cpu list counter to be out of sync with the per-cpu list contents if a struct page is corrupted.
The consequence is an infinite loop if the per-cpu lists get fully drained by free_pcppages_bulk because all the lists are empty but the count is positive. The infinite loop occurs here
do {
batch_free++;
if (++migratetype == MIGRATE_PCPTYPES)
migratetype = 0;
list = &pcp->lists[migratetype];
} while (list_empty(list));What the user sees is a bad page warning followed by a soft lockup with interrupts disabled in free_pcppages_bulk().
This patch keeps the accounting in sync.
--- mm/page_alloc.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
mm/page_alloc.c +10 -2
@@ -2192,7 +2192,7 @@ static int rmqueue_bulk(struct zone *zon unsigned long count, struct list_head *list, int migratetype, bool cold) { - int i; + int i, alloced = 0;spin_lock (&zone->lock);for (i =0 ; i < count; ++i) {
@@ -2217,13 +2217,21 @@ static int rmqueue_bulk(struct zone *zonelse list_add_tail (&page->lru, list); list = &page->lru; + alloced++;if (is_migrate_cma (get_pcppage_migratetype (page)))__mod_zone_page_state (zone,NR_FREE_CMA_PAGES , -(1 << order)); } + +/* +* i pages were removed from the buddy list even if some leak due +* to check_pcp_refill failing so adjust NR_FREE_PAGES based +* on i. Do not confuse with 'alloced' which is the number of +* pages added to the pcp list. +*/ __mod_zone_page_state (zone,NR_FREE_PAGES , -(i << order));spin_unlock (&zone->lock); -return i; +return alloced; }#ifdef CONFIG_NUMA
Patches currently in stable-queue which might be from [email protected] are
queue-4.9/mm-page_alloc-keep-pcp-count-and-list-contents-in-sync-if-struct-page-is-corrupted.patch