redonkable
/
alistair23-linux
1
0
Fork 0
Code Releases Activity

Documentation/kmemleak.txt: updates 

Update Documentatin/kmemleak.txt to reflect the following changes:

Commit b69ec42b1b ("Kconfig: clean up the long arch list for the
DEBUG_KMEMLEAK config option") made it so that we can't check supported
architectures by read Kconfig.debug.

Commit 85d3a316c7 ("kmemleak: use rbtree instead of prio tree")
converted kmemleak to use rbtree instead of prio tree.

Signed-off-by: Wang YanQing <udknight@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
hifive-unleashed-5.1
Wang YanQing 2014-04-03 14:50:38 -07:00 committed by Linus Torvalds
parent 31e143686a
commit 4762c98413
1 changed files with 3 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
Documentation/kmemleak.txt
View File

@ -11,9 +11,7 @@ with the difference that the orphan objects are not freed but only
reported via /sys/kernel/debug/kmemleak. A similar method is used by the
Valgrind tool (memcheck --leak-check) to detect the memory leaks in
user-space applications.
Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug for supported
architectures.
Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, ppc, mips, s390, metag and tile.
Usage
-----
@ -69,7 +67,7 @@ Basic Algorithm
The memory allocations via kmalloc, vmalloc, kmem_cache_alloc and
friends are traced and the pointers, together with additional
information like size and stack trace, are stored in a prio search tree.
information like size and stack trace, are stored in a rbtree.
The corresponding freeing function calls are tracked and the pointers
removed from the kmemleak data structures.
@ -85,7 +83,7 @@ The scanning algorithm steps:
1. mark all objects as white (remaining white objects will later be
considered orphan)
2. scan the memory starting with the data section and stacks, checking
the values against the addresses stored in the prio search tree. If
the values against the addresses stored in the rbtree. If
a pointer to a white object is found, the object is added to the
gray list
3. scan the gray objects for matching addresses (some white objects