summaryrefslogtreecommitdiffstats
path: root/Documentation/kmemleak.txt
diff options
context:
space:
mode:
authorLuis R. Rodriguez <lrodriguez@Atheros.com>2009-09-04 17:44:51 -0700
committerCatalin Marinas <catalin.marinas@arm.com>2009-09-08 16:36:08 +0100
commit30b3710105be0ba6bbdb7d7d126af76246b02eba (patch)
tree84200b02f8230f3706744512bf4ba68341d9b889 /Documentation/kmemleak.txt
parent4a558dd6f93d419cd318958577e25492bd09e960 (diff)
downloadop-kernel-dev-30b3710105be0ba6bbdb7d7d126af76246b02eba.zip
op-kernel-dev-30b3710105be0ba6bbdb7d7d126af76246b02eba.tar.gz
kmemleak: add clear command support
In an ideal world your kmemleak output will be small, when its not (usually during initial bootup) you can use the clear command to ingore previously reported and unreferenced kmemleak objects. We do this by painting all currently reported unreferenced objects grey. We paint them grey instead of black to allow future scans on the same objects as such objects could still potentially reference newly allocated objects in the future. To test a critical section on demand with a clean /sys/kernel/debug/kmemleak you can do: echo clear > /sys/kernel/debug/kmemleak test your kernel or modules echo scan > /sys/kernel/debug/kmemleak Then as usual to get your report with: cat /sys/kernel/debug/kmemleak Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Diffstat (limited to 'Documentation/kmemleak.txt')
-rw-r--r--Documentation/kmemleak.txt30
1 files changed, 30 insertions, 0 deletions
diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
index c223785..34f6638 100644
--- a/Documentation/kmemleak.txt
+++ b/Documentation/kmemleak.txt
@@ -27,6 +27,13 @@ To trigger an intermediate memory scan:
# echo scan > /sys/kernel/debug/kmemleak
+To clear the list of all current possible memory leaks:
+
+ # echo clear > /sys/kernel/debug/kmemleak
+
+New leaks will then come up upon reading /sys/kernel/debug/kmemleak
+again.
+
Note that the orphan objects are listed in the order they were allocated
and one object at the beginning of the list may cause other subsequent
objects to be reported as orphan.
@@ -42,6 +49,8 @@ Memory scanning parameters can be modified at run-time by writing to the
scan=<secs> - set the automatic memory scanning period in seconds
(default 600, 0 to stop the automatic scanning)
scan - trigger a memory scan
+ clear - clear list of current memory leak suspects, done by
+ marking all current reported unreferenced objects grey
dump=<addr> - dump information about the object found at <addr>
Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on
@@ -87,6 +96,27 @@ avoid this, kmemleak can also store the number of values pointing to an
address inside the block address range that need to be found so that the
block is not considered a leak. One example is __vmalloc().
+Testing specific sections with kmemleak
+---------------------------------------
+
+Upon initial bootup your /sys/kernel/debug/kmemleak output page may be
+quite extensive. This can also be the case if you have very buggy code
+when doing development. To work around these situations you can use the
+'clear' command to clear all reported unreferenced objects from the
+/sys/kernel/debug/kmemleak output. By issuing a 'scan' after a 'clear'
+you can find new unreferenced objects; this should help with testing
+specific sections of code.
+
+To test a critical section on demand with a clean kmemleak do:
+
+ # echo clear > /sys/kernel/debug/kmemleak
+ ... test your kernel or modules ...
+ # echo scan > /sys/kernel/debug/kmemleak
+
+Then as usual to get your report with:
+
+ # cat /sys/kernel/debug/kmemleak
+
Kmemleak API
------------
OpenPOWER on IntegriCloud