The patch titled
Subject: mm: make vb_alloc() more foolproof
has been added to the -mm tree. Its filename is
mm-make-vb_alloc-more-foolproof.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Jan Kara <jack@xxxxxxx>
Subject: 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.
Signed-off-by: Jan Kara <jack@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/vmalloc.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff -puN mm/vmalloc.c~mm-make-vb_alloc-more-foolproof mm/vmalloc.c
--- a/mm/vmalloc.c~mm-make-vb_alloc-more-foolproof
+++ a/mm/vmalloc.c
@@ -904,6 +904,15 @@ static void *vb_alloc(unsigned long size
BUG_ON(size & ~PAGE_MASK);
BUG_ON(size > PAGE_SIZE*VMAP_MAX_ALLOC);
+ if (size == 0) {
+ /*
+ * Allocating 0 bytes isn't what caller wants since
+ * get_order(0) returns funny result. Just warn and terminate
+ * early.
+ */
+ WARN_ON(1);
+ return NULL;
+ }
order = get_order(size);
again:
_
Subject: Subject: mm: make vb_alloc() more foolproof
Patches currently in -mm which might be from jack@xxxxxxx are
linux-next.patch
mm-make-vb_alloc-more-foolproof.patch
mm-make-vb_alloc-more-foolproof-fix.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
