Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Help to understand that call trace
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
Logicien
Veteran
Veteran


Joined: 16 Sep 2005
Posts: 1555
Location: Montréal

PostPosted: Fri Nov 09, 2012 1:43 am    Post subject: Help to understand that call trace Reply with quote

So far, there is only one message who can indicate the source of the call trace before it appear
Code:
kmemleak: Trying to color unknown object at 0xffff88012a80aa80 as Grey
Pid: 0, comm: swapper/0 Not tainted 3.6.5-gentoo #1
Call Trace:
 [<ffffffff810cc87f>] ? paint_ptr+0x50/0x8f
 [<ffffffff816908e9>] ? sysctl_init+0x16/0x1b
 [<ffffffff8167da99>] ? start_kernel+0x38c/0x3cd
 [<ffffffff8167d5b0>] ? do_early_param+0x7d/0x7d
 [<ffffffff8167d120>] ? early_idt_handlers+0x120/0x120
 [<ffffffff8167d331>] ? x86_64_start_kernel+0xd3/0xe2

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
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Fri Nov 09, 2012 3:25 pm    Post subject: Reply with quote

Logicien ...

when colouring "grey" kmemleak is trying to mark it as a false positive. The line above whats quoted should give some idea of what specificaly triggers it.

best ... khay
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Mon Nov 12, 2012 11:40 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2280
Location: Adendorf, Germany

PostPosted: Tue Nov 13, 2012 8:10 am    Post subject: Reply with quote

Little addition: You might want to take a look at /usr/src/linux/Documentation/kmemleak.txt.
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Wed Nov 14, 2012 2:40 pm    Post subject: Reply with quote

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.

edit:
Theoretic, functional programming kind of question:
do kmemleak's own function arguments count as
references?
_________________
TIA
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Thu Nov 15, 2012 12:20 am    Post subject: Reply with quote

Quote:
/usr/src/linux/Documentation/kmemleak.txt


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).

Here is a good explanation (last time I read it, anyway) of
what "race conditons" are:
http://en.wikipedia.org/wiki/Race_condition

This sentence from kmemleak.txt is pertinent:
Quote:

Anyway, this tool is intended for debugging purposes where
the performance might not be the most important requirement.


Most users are not debugging kernel memory leaks, so
they do not need to pay the performance costs of enabling
kmemleak.
_________________
TIA
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum