Linux-3.14.12 memory management notes [memory leak detection kmemleak example] [transfer]

This article is reproduced from: http://blog.chinaunix.net/uid-26859697-id-5758037.html

After analyzing the kmemleak implementation, experiment as usual to make sure it functions properly.

Like kmemcheck, this feature needs to be enabled when the kernel is enabled. The main configuration items are: CONFIG_DEBUG_KERNEL, CONFIG_HAVE_DEBUG_KMEMLEAK, CONFIG_DEBUG_KMEMLEAK, and CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE for the number of configuration information records. Usually, the number of configurations does not need to be modified, but for the self-starting initialization module, it is necessary to make adjustments to record more information to avoid omission.

For the above items, when make menuconfig compiles and configures the kernel, the configuration path is as follows:

Kernel hacking

+——>Kernel Debugging (this item needs to be enabled)

+——>Memory Debugging

    +——>Kernel memory leak detector (open this item)

Of course, these configuration items have certain dependencies on other configuration items. For details, you can find out about the corresponding configuration items in the make menuconfig backslash search.

There are several items that need special attention during the setting process. After the "Kernel memory leak detector" is turned on, be careful not to set several sub-items, including: "Simple test for the kernel memory leak detector" and "Default" kmemleak to off”.

For example, the configuration options in the experiment are set as follows:

After compiling the kernel, install the debug version of the kernel, restart the Linux system, and enter the new kernel. You will be able to see the existence of the path file /sys/kernel/debug/kmemleak. If it exists, it indicates that the opening is successful.

    This experiment still uses a 64-bit system as a demonstration, modifying the previous kmemcheck experimental code to construct a memory leak. The specific code is as follows:

1. #include <linux/init.h>
2. #include <linux/module.h>
3. #include <linux/mm.h>
4. #include <linux/slab.h>
5. #include <asm/page.h>
6.  
7. void kmemleak_memalloc(void)
8. {
9.     char *pmem;
10.    
11.     pmem = kmalloc(300, GFP_KERNEL);
12.     if (!pmem)
13.     {
14.         printk("[Kmemleak]: kmalloc fail!\n");
15.     }
16.     else
17.     {
18.         printk("[Kmemleak]: kmalloc return %p \n", pmem);
19.     } 
20. }
21.  
22. int __init kmemleak_test_init(void)
23. {
24.    
25.     printk("[Kmemleak]: kmemleak_test_init! \n");
26.  
27.     kmemleak_memalloc();
28.  
29.     return 0;
30. }
31.  
32. void __exit kmemleak_test_exit(void)
33. {
34.     printk("[Kmemleak]: kmemleak_test_exit now \n");
35. }
36.  
37.  
38. module_init(kmemleak_test_init)
39. module_exit(kmemleak_test_exit)
40.  
41. MODULE_LICENSE("GPL");

 

    The Makefile script is slightly modified:

1. obj-m = kmemleak_test.o
2.  
3. all:
4.     make -C /lib/modules/`uname -r`/build M=`pwd`
5.  
6. clean:
7.     rm -f *.o *.ko *.mod.c modules.order Module.symvers

 

    After compiling the kernel ko, install the module through the ismod command, and confirm through dmesg that the module is initialized and the memory application is appropriate according to the log information printed by the code.

    Related information is as follows:

 

In order to ensure the success of the experiment, after ko is installed, wait a few minutes.

Run the command: echo scan > /sys/kernel/debug/kmemleak to perform memory scan detection. Detection results will be recorded in the /sys/kernel/debug/kmemleak file. Through the information of dmesg, you can see that the requested memory space is located at the address 0xffff95c9bf81b600. Search for it, and you can see the information records in kmemleak:

 

In the detection result information of kmemleak, the call stack information of the memory application, the information of the 32byte memory header, and the leaked memory address and size are clearly recorded. However, the size here is not a very precise size. Here is the size of a slab memory slice. The size of the space requested in the experiment is 300 bytes, which corresponds to a slab of 512 bytes. The specific part of combining code analysis is omitted, which is a necessary basic ability for developers, and I will not make a move.

Next, the control parameters of kmemleak are described in detail. The control of kmemleak is mainly by writing parameters to the /sys/kernel/debug/kmemleak file. For example, the previous command to enable kmemleak to scan for memory leaks is to write scan, and the specific command is: echo scan > /sys/kernel/debug/kmemleak. The parameter used to clear the scan result of kmemleak is clear, and the corresponding command is: echo clear > /sys/kernel/debug/kmemleak.

More kmemleak parameters are:

1. off - disable kmemleak (irreversible)
2.   stack=on - enable the task stacks scanning (default)
3.   stack=off - disable the tasks stacks scanning
4.   scan=on - start the automatic memory scanning thread (default)
5.   scan=off - stop the automatic memory scanning thread
6.   scan=<secs> - set the automatic memory scanning period in seconds
7.           (default 600, 0 to stop the automatic scanning)
8.   scan - trigger a memory scan
9.   clear - clear list of current memory leak suspects, done by
10.           marking all current reported unreferenced objects grey
11.   dump=<addr> - dump information about the object found at <addr>

 

If testing a kernel module, the correct procedure should be:

1. Clear the history information of kmemleak in order to record new data:

#echo clear > /sys/kernel/debug/kmemleak

2. Load the kernel module to be tested and execute the relevant test cases;

#ismod ***. ko

3. Enable kmemleak to scan for memory leaks:

#echo scan > /sys/kernel/debug/kmemleak

4. View the analysis scan results:

#cat /sys/kernel/debug/kmemleak

    At this point, the experiment is completed, kmemleak is very useful, suitable for kernel module development to detect and locate memory leaks.