![]() | |||||||||||||
Messages in this thread |
Andrew Morton wrote: > On Wed, 5 Dec 2007 10:52:48 +0100 (CET) > Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote: > >> -------------------------------------------------------------------------------- >> Subject: sparsemem: sparse_add_one_section() may fail to allocate memory >> >> sparsemem: sparse_add_one_section() may fail to allocate memory, and must check >> whether the allocation succeeded before proceeding to touch the allocated >> memory. >> >> From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> >> >> Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> >> --- >> FIXME There are still some possible memory leaks in sparse_add_one_section(): >> - usemap is never deallocated >> - __kfree_section_memmap() is a not yet implemented dummy > > I already had > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-improve-the-error-handling-for-sparse_add_one_section.patch > and > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-check-the-return-value-of-sparse_index_alloc.patch > > queued. Do they fix the problem, and should they be merged in 2.6.24? No, a quick test shows it just panics in a different place. Geert's patch does also. I'll try Milton's suggestion to pre-allocate the memory early. It seems that should work as long as nothing else before the hot-plug mem is added needs a large chunk. -Geoff | ||||||||||||
| Last update: 2007-12-06 00:47 [from the cache] ©2003-2008 | |||||||||||||