Root/
1 | Kernel Memory Leak Detector |
2 | =========================== |
3 | |
4 | Introduction |
5 | ------------ |
6 | |
7 | Kmemleak provides a way of detecting possible kernel memory leaks in a |
8 | way similar to a tracing garbage collector |
9 | (http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Tracing_garbage_collectors), |
10 | with the difference that the orphan objects are not freed but only |
11 | reported via /sys/kernel/debug/kmemleak. A similar method is used by the |
12 | Valgrind tool (memcheck --leak-check) to detect the memory leaks in |
13 | user-space applications. |
14 | |
15 | Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug for supported |
16 | architectures. |
17 | |
18 | Usage |
19 | ----- |
20 | |
21 | CONFIG_DEBUG_KMEMLEAK in "Kernel hacking" has to be enabled. A kernel |
22 | thread scans the memory every 10 minutes (by default) and prints the |
23 | number of new unreferenced objects found. To display the details of all |
24 | the possible memory leaks: |
25 | |
26 | # mount -t debugfs nodev /sys/kernel/debug/ |
27 | # cat /sys/kernel/debug/kmemleak |
28 | |
29 | To trigger an intermediate memory scan: |
30 | |
31 | # echo scan > /sys/kernel/debug/kmemleak |
32 | |
33 | To clear the list of all current possible memory leaks: |
34 | |
35 | # echo clear > /sys/kernel/debug/kmemleak |
36 | |
37 | New leaks will then come up upon reading /sys/kernel/debug/kmemleak |
38 | again. |
39 | |
40 | Note that the orphan objects are listed in the order they were allocated |
41 | and one object at the beginning of the list may cause other subsequent |
42 | objects to be reported as orphan. |
43 | |
44 | Memory scanning parameters can be modified at run-time by writing to the |
45 | /sys/kernel/debug/kmemleak file. The following parameters are supported: |
46 | |
47 | off - disable kmemleak (irreversible) |
48 | stack=on - enable the task stacks scanning (default) |
49 | stack=off - disable the tasks stacks scanning |
50 | scan=on - start the automatic memory scanning thread (default) |
51 | scan=off - stop the automatic memory scanning thread |
52 | scan=<secs> - set the automatic memory scanning period in seconds |
53 | (default 600, 0 to stop the automatic scanning) |
54 | scan - trigger a memory scan |
55 | clear - clear list of current memory leak suspects, done by |
56 | marking all current reported unreferenced objects grey |
57 | dump=<addr> - dump information about the object found at <addr> |
58 | |
59 | Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on |
60 | the kernel command line. |
61 | |
62 | Memory may be allocated or freed before kmemleak is initialised and |
63 | these actions are stored in an early log buffer. The size of this buffer |
64 | is configured via the CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE option. |
65 | |
66 | Basic Algorithm |
67 | --------------- |
68 | |
69 | The memory allocations via kmalloc, vmalloc, kmem_cache_alloc and |
70 | friends are traced and the pointers, together with additional |
71 | information like size and stack trace, are stored in a prio search tree. |
72 | The corresponding freeing function calls are tracked and the pointers |
73 | removed from the kmemleak data structures. |
74 | |
75 | An allocated block of memory is considered orphan if no pointer to its |
76 | start address or to any location inside the block can be found by |
77 | scanning the memory (including saved registers). This means that there |
78 | might be no way for the kernel to pass the address of the allocated |
79 | block to a freeing function and therefore the block is considered a |
80 | memory leak. |
81 | |
82 | The scanning algorithm steps: |
83 | |
84 | 1. mark all objects as white (remaining white objects will later be |
85 | considered orphan) |
86 | 2. scan the memory starting with the data section and stacks, checking |
87 | the values against the addresses stored in the prio search tree. If |
88 | a pointer to a white object is found, the object is added to the |
89 | gray list |
90 | 3. scan the gray objects for matching addresses (some white objects |
91 | can become gray and added at the end of the gray list) until the |
92 | gray set is finished |
93 | 4. the remaining white objects are considered orphan and reported via |
94 | /sys/kernel/debug/kmemleak |
95 | |
96 | Some allocated memory blocks have pointers stored in the kernel's |
97 | internal data structures and they cannot be detected as orphans. To |
98 | avoid this, kmemleak can also store the number of values pointing to an |
99 | address inside the block address range that need to be found so that the |
100 | block is not considered a leak. One example is __vmalloc(). |
101 | |
102 | Testing specific sections with kmemleak |
103 | --------------------------------------- |
104 | |
105 | Upon initial bootup your /sys/kernel/debug/kmemleak output page may be |
106 | quite extensive. This can also be the case if you have very buggy code |
107 | when doing development. To work around these situations you can use the |
108 | 'clear' command to clear all reported unreferenced objects from the |
109 | /sys/kernel/debug/kmemleak output. By issuing a 'scan' after a 'clear' |
110 | you can find new unreferenced objects; this should help with testing |
111 | specific sections of code. |
112 | |
113 | To test a critical section on demand with a clean kmemleak do: |
114 | |
115 | # echo clear > /sys/kernel/debug/kmemleak |
116 | ... test your kernel or modules ... |
117 | # echo scan > /sys/kernel/debug/kmemleak |
118 | |
119 | Then as usual to get your report with: |
120 | |
121 | # cat /sys/kernel/debug/kmemleak |
122 | |
123 | Kmemleak API |
124 | ------------ |
125 | |
126 | See the include/linux/kmemleak.h header for the functions prototype. |
127 | |
128 | kmemleak_init - initialize kmemleak |
129 | kmemleak_alloc - notify of a memory block allocation |
130 | kmemleak_alloc_percpu - notify of a percpu memory block allocation |
131 | kmemleak_free - notify of a memory block freeing |
132 | kmemleak_free_part - notify of a partial memory block freeing |
133 | kmemleak_free_percpu - notify of a percpu memory block freeing |
134 | kmemleak_not_leak - mark an object as not a leak |
135 | kmemleak_ignore - do not scan or report an object as leak |
136 | kmemleak_scan_area - add scan areas inside a memory block |
137 | kmemleak_no_scan - do not scan a memory block |
138 | kmemleak_erase - erase an old value in a pointer variable |
139 | kmemleak_alloc_recursive - as kmemleak_alloc but checks the recursiveness |
140 | kmemleak_free_recursive - as kmemleak_free but checks the recursiveness |
141 | |
142 | Dealing with false positives/negatives |
143 | -------------------------------------- |
144 | |
145 | The false negatives are real memory leaks (orphan objects) but not |
146 | reported by kmemleak because values found during the memory scanning |
147 | point to such objects. To reduce the number of false negatives, kmemleak |
148 | provides the kmemleak_ignore, kmemleak_scan_area, kmemleak_no_scan and |
149 | kmemleak_erase functions (see above). The task stacks also increase the |
150 | amount of false negatives and their scanning is not enabled by default. |
151 | |
152 | The false positives are objects wrongly reported as being memory leaks |
153 | (orphan). For objects known not to be leaks, kmemleak provides the |
154 | kmemleak_not_leak function. The kmemleak_ignore could also be used if |
155 | the memory block is known not to contain other pointers and it will no |
156 | longer be scanned. |
157 | |
158 | Some of the reported leaks are only transient, especially on SMP |
159 | systems, because of pointers temporarily stored in CPU registers or |
160 | stacks. Kmemleak defines MSECS_MIN_AGE (defaulting to 1000) representing |
161 | the minimum age of an object to be reported as a memory leak. |
162 | |
163 | Limitations and Drawbacks |
164 | ------------------------- |
165 | |
166 | The main drawback is the reduced performance of memory allocation and |
167 | freeing. To avoid other penalties, the memory scanning is only performed |
168 | when the /sys/kernel/debug/kmemleak file is read. Anyway, this tool is |
169 | intended for debugging purposes where the performance might not be the |
170 | most important requirement. |
171 | |
172 | To keep the algorithm simple, kmemleak scans for values pointing to any |
173 | address inside a block's address range. This may lead to an increased |
174 | number of false negatives. However, it is likely that a real memory leak |
175 | will eventually become visible. |
176 | |
177 | Another source of false negatives is the data stored in non-pointer |
178 | values. In a future version, kmemleak could only scan the pointer |
179 | members in the allocated structures. This feature would solve many of |
180 | the false negative cases described above. |
181 | |
182 | The tool can report false positives. These are cases where an allocated |
183 | block doesn't need to be freed (some cases in the init_call functions), |
184 | the pointer is calculated by other methods than the usual container_of |
185 | macro or the pointer is stored in a location not scanned by kmemleak. |
186 | |
187 | Page allocations and ioremap are not tracked. |
188 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9