Skip to content

Commit

Permalink
Documentation/kmemleak.txt: updates
Browse files Browse the repository at this point in the history
Update Documentatin/kmemleak.txt to reflect the following changes:

Commit b69ec42 ("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 85d3a31 ("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>
  • Loading branch information
Wang YanQing authored and Linus Torvalds committed Apr 3, 2014
1 parent 31e1436 commit 4762c98
Showing 1 changed file with 3 additions and 5 deletions.
8 changes: 3 additions & 5 deletions Documentation/kmemleak.txt
Original file line number Diff line number Diff line change
Expand Up @@ -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
-----
Expand Down Expand Up @@ -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.

Expand All @@ -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
Expand Down

0 comments on commit 4762c98

Please sign in to comment.