[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0000013e7f651028-9a57bc30-4148-4aba-a0e6-737b83bf2458-000000@email.amazonses.com>
Date: Tue, 7 May 2013 14:28:49 +0000
From: Christoph Lameter <cl@...ux.com>
To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
cc: glommer@...allels.com, penberg@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [linux-next-20130422] Bug in SLAB?
On Tue, 7 May 2013, Tetsuo Handa wrote:
> > These are exclusively from the module load. So the kernel seems to be
> > clean of large kmalloc's ?
> >
> There are modules (e.g. TOMOYO) which do not check for KMALLOC_MAX_SIZE limit
> and expect kmalloc() larger than KMALLOC_MAX_SIZE bytes to return NULL.
Dont do that. Please fix these things. The slab allocators are for small
allocations not large ones like these. There are page allocator functions
that allow higher order allocations if contiguous memory is needed and
there is vmalloc that makes it safe. We recently added a CMA allocator
specifically for these large contiguous physical allocations.
> As far as I know, such modules sequentially double the buffer size. Therefore,
> as long as request for KMALLOC_MAX_SIZE * 2 bytes returns NULL, they won't
> trigger oops by requesting for KMALLOC_MAX_SIZE * 8 bytes.
Please use vmalloc for these large allocs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists