Re: [PATCH 00/14] Kernel memory leak detector

[Catalin Marinas]

On Thu, 2009-01-15 at 17:09 -0500, Mike Snitzer wrote:
> When running your latest git kmemleak branch (as is being pulled into
> linux-next AFAIK) I'm still seeing that kmemleak fails to initialize
> with:
> 
> kmemleak: Early log buffer exceeded
[...]
> Kernel memory leak detector disabled

It looks like kmemleak exceeded it's buffer for logging initial memory
allocations requests and disabled itself (since it needs to track all
the memory allocations and kmemleak uses the slab allocator itself, it
uses this buffer). You can try to increase the size of the early_log[]
array (currently 200) in the kmemleak.c file. The current size was fine
on my embedded systems but, well, it looks like it needs to be
increased.

> Doing so yields:
>   MODPOST vmlinux.o
> WARNING: vmlinux.o(.text+0xaed80): Section mismatch in reference from
> the function kmemleak_free() to the function .init.text:log_early()
> The function kmemleak_free() references
> the function __init log_early().
> This is often because kmemleak_free lacks a __init
> annotation or the annotation of log_early is wrong.

That's related to the early_log buffer. Once kmemleak was initialised,
it no longer calls the log_early() function and doesn't use the
early_log[] array, hence they were marked as __init. The warning is
valid but it doesn't cause any bugs in kmemleak. Any idea how to avoid
this warning and still release the __init code and data?

Another solution is to use the page allocator for the early logging
buffer and just free the pages once fully initialised, though this may
complicate the code slightly more.

-- 
Catalin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/