We got migratetype without holding the lock so it could be
racy. If some pages go on the isolate migratetype buddy list
by this race, we can't allocate this page anymore until next
isolation attempt on this pageblock. Below is possible
scenario of this race.
pageblock 1 is isolate migratetype.
CPU1 CPU2
- get_pfnblock_migratetype(pageblock 1),
so MIGRATE_ISOLATE is returned
- call free_one_page() with MIGRATE_ISOLATE
- grab the zone lock
- unisolate pageblock 1
- release the zone lock
- grab the zone lock
- call __free_one_page() with MIGRATE_ISOLATE
- free page go into isolate buddy list
and we can't use it anymore
To prevent this possibility, re-check migratetype with holding the lock.
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
---
mm/page_alloc.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 99c05f7..d8feedc 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -743,6 +743,17 @@ static void free_one_page(struct zone *zone,
spin_lock(&zone->lock);
zone->pages_scanned = 0;
+ if (unlikely(is_migrate_isolate(migratetype))) {
+ /*
+ * We got migratetype without holding the lock so it could be
+ * racy. If some pages go on the isolate migratetype buddy list
+ * by this race, we can't allocate this page anymore until next
+ * isolation attempt on this pageblock. To prevent this
+ * possibility, re-check migratetype with holding the lock.
+ */
+ migratetype = get_pfnblock_migratetype(page, pfn);
+ }
+
__free_one_page(page, pfn, zone, order, migratetype);
if (!is_migrate_isolate(migratetype))
__mod_zone_freepage_state(zone, 1 << order, migratetype);