forked from luck/tmp_suning_uos_patched
mm: alloc_large_system_hash check order
On an x86_64 with 4GB ram, tcp_init()'s call to alloc_large_system_hash(), to allocate tcp_hashinfo.ehash, is now triggering an mmotm WARN_ON_ONCE on order >= MAX_ORDER - it's hoping for order 11. alloc_large_system_hash() had better make its own check on the order. Signed-off-by: Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: David Miller <davem@davemloft.net> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Eric Dumazet <dada1@cosmosbay.com> Cc: Christoph Lameter <cl@linux.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
parent
58568d2a82
commit
6c0db4664b
|
@ -4511,7 +4511,10 @@ void *__init alloc_large_system_hash(const char *tablename,
|
|||
table = __vmalloc(size, GFP_ATOMIC, PAGE_KERNEL);
|
||||
else {
|
||||
unsigned long order = get_order(size);
|
||||
table = (void*) __get_free_pages(GFP_ATOMIC, order);
|
||||
|
||||
if (order < MAX_ORDER)
|
||||
table = (void *)__get_free_pages(GFP_ATOMIC,
|
||||
order);
|
||||
/*
|
||||
* If bucketsize is not a power-of-two, we may free
|
||||
* some pages at the end of hash table.
|
||||
|
|
Loading…
Reference in New Issue
Block a user