blob: c7b27634d64e01c0b8753f0f2f9e98b2b3de2e48 [file] [log] [blame]
From 0b3281a333d8bc5140e4439d52c46f1e6b897b2b Mon Sep 17 00:00:00 2001
From: Kuppuswamy Sathyanarayanan <>
Date: Tue, 13 Aug 2019 15:37:31 -0700
Subject: [PATCH] mm/vmalloc.c: fix percpu free VM area search criteria
commit 5336e52c9e46afa69b7a85a0a091f0e4daa23d6e upstream.
Recent changes to the vmalloc code by commit 68ad4a330433
("mm/vmalloc.c: keep track of free blocks for vmap allocation") can
cause spurious percpu allocation failures. These, in turn, can result
in panic()s in the slub code. One such possible panic was reported by
Dave Hansen in following link
Another related panic observed is,
RIP: 0033:0x7f46f7441b9b
Call Trace:
VMALLOC memory manager divides the entire VMALLOC space (VMALLOC_START
to VMALLOC_END) into multiple VM areas (struct vm_areas), and it mainly
uses two lists (vmap_area_list & free_vmap_area_list) to track the used
and free VM areas in VMALLOC space. And pcpu_get_vm_areas(offsets[],
sizes[], nr_vms, align) function is used for allocating congruent VM
areas for percpu memory allocator. In order to not conflict with
VMALLOC users, pcpu_get_vm_areas allocates VM areas near the end of the
VMALLOC space. So the search for free vm_area for the given requirement
starts near VMALLOC_END and moves upwards towards VMALLOC_START.
Prior to commit 68ad4a330433, the search for free vm_area in
pcpu_get_vm_areas() involves following two main steps.
Step 1:
Find a aligned "base" adress near VMALLOC_END.
va = free vm area near VMALLOC_END
Step 2:
Loop through number of requested vm_areas and check,
Step 2.1:
if (base < VMALLOC_START)
1. fail with error
Step 2.2:
// end is offsets[area] + sizes[area]
if (base + end > va->vm_end)
1. Move the base downwards and repeat Step 2
Step 2.3:
if (base + start < va->vm_start)
1. Move to previous free vm_area node, find aligned
base address and repeat Step 2
But Commit 68ad4a330433 removed Step 2.2 and modified Step 2.3 as below:
Step 2.3:
if (base + start < va->vm_start || base + end > va->vm_end)
1. Move to previous free vm_area node, find aligned
base address and repeat Step 2
Above change is the root cause of spurious percpu memory allocation
failures. For example, consider a case where a relatively large vm_area
(~ 30 TB) was ignored in free vm_area search because it did not pass the
base + end < vm->vm_end boundary check. Ignoring such large free
vm_area's would lead to not finding free vm_area within boundary of
VMALLOC_start to VMALLOC_END which in turn leads to allocation failures.
So modify the search algorithm to include Step 2.2.
Fixes: 68ad4a330433 ("mm/vmalloc.c: keep track of free blocks for vmap allocation")
Signed-off-by: Kuppuswamy Sathyanarayanan <>
Reported-by: Dave Hansen <>
Acked-by: Dennis Zhou <>
Reviewed-by: Uladzislau Rezki (Sony) <>
Cc: Roman Gushchin <>
Cc: sathyanarayanan kuppuswamy <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Paul Gortmaker <>
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 63f2f39dcb26..a47187f486ec 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3254,10 +3254,20 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets,
if (va == NULL)
goto overflow;
+ /*
+ * If required width exeeds current VA block, move
+ * base downwards and then recheck.
+ */
+ if (base + end > va->va_end) {
+ base = pvm_determine_end_from_reverse(&va, align) - end;
+ term_area = area;
+ continue;
+ }
* If this VA does not fit, move base downwards and recheck.
- if (base + start < va->va_start || base + end > va->va_end) {
+ if (base + start < va->va_start) {
va = node_to_va(rb_prev(&va->rb_node));
base = pvm_determine_end_from_reverse(&va, align) - end;
term_area = area;