summaryrefslogtreecommitdiff
path: root/mm/vmalloc.c
diff options
context:
space:
mode:
authorJan Kara <jack@suse.cz>2012-07-31 16:41:37 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2012-07-31 18:42:39 -0700
commitaa91c4d898c062804f4d0a5da6d8ab013cd0e868 (patch)
treeb4472de48394ca8aafac72e2e97eb9a259fd8111 /mm/vmalloc.c
parent92ca922f0a19145f2dcc99d84fe656fa55b52c2e (diff)
mm: make vb_alloc() more foolproof
If someone calls vb_alloc() (or vm_map_ram() for that matter) to allocate 0 bytes (0 pages), get_order() returns BITS_PER_LONG - PAGE_CACHE_SHIFT and interesting stuff happens. So make debugging such problems easier and warn about 0-size allocation. [akpm@linux-foundation.org: use WARN_ON-return-value feature] Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/vmalloc.c')
-rw-r--r--mm/vmalloc.c8
1 files changed, 8 insertions, 0 deletions
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 7e25ee3ce6e5..2bb90b1d241c 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -904,6 +904,14 @@ static void *vb_alloc(unsigned long size, gfp_t gfp_mask)
BUG_ON(size & ~PAGE_MASK);
BUG_ON(size > PAGE_SIZE*VMAP_MAX_ALLOC);
+ if (WARN_ON(size == 0)) {
+ /*
+ * Allocating 0 bytes isn't what caller wants since
+ * get_order(0) returns funny result. Just warn and terminate
+ * early.
+ */
+ return NULL;
+ }
order = get_order(size);
again: