So, this call trace look to come from kmemleak. I do not know what is kmemleak. This kernel have been configure and compile by my self from the Gentoo sources. This is 3.6.5 version, but the call trace is displayed since long before. The kernel work normally._________________Paul

What is the function of kmemleak? To notice when the kernel
has allocated memory to which there are no longer any
references, meaning that the address of that memory block
is no longer assigned to any variable, yet the memory block
is still marked as allocated by the kernel.

"Coloring" in this case is kernel shorthand for "allocated but
not referenced", "allocated and referenced", "not allocated,"
etc. False positives can turn up when the address of a block
of memory is on a queue to be freed when the kernel gets
around to it. Until the kernel actually marks it free, it seems
to still be allocated to the kmemleak detector, yet some
structure that once contained a variable that held the address
of that memory block no longer exists (kernel thread exited,
stack was freed, etc). So it is not really a "memory leak",
because the kernel will get around to freeing it eventually,
yet it still looks like a memory leak when kmemleak gets
scheduled.

That is what kmemleak does. Why there is a bug report
would have a more subtle explanation. (I do not know
enough about its internal structure to say.)_________________TIA

Little addition: You might want to take a look at /usr/src/linux/Documentation/kmemleak.txt._________________elogindCygwinOnSteroids
"A conservative is a man who is too cowardly to fight and too fat to run."
-- Elbert Hubbard

Another added detail: kmemleak should not report a leak when
memory is on a queue to be freed, because the queue itself
contains a reference to that block of memory. That would be a
bug.

There might be race conditions, though, where removing that
variable from the queue and marking that block of memory
as free, unallocated memory is not an atomic operation.
*Something* should always have a reference to that memory
until it is actually marked free, but perhaps there are situations
where kmemleak can not see local stack variables of some
function currently executing in another thread on another
cpu core, for example, and that is the only existing reference
to that memory block.

A good document. When you consider how many kinds of
cases there are where coverage of allocations and references
to them from kernel objects would not be complete, races
between kmemleak and non-atomic deallocation functions
are probably in the noise (not a source of errors common
enough to matter to anyone examining kernel memory leaks).