how to determine if a Linux kernel module is leaking memory

For testing the behavior of the kernel when it leaks memory, I am writing a kernel module that continuously allocates memory e.g. the code look开发者_Go百科s like

int bytesLeaked = 128000;
char *var = kmalloc(bytesLeaked, GFP_KERNEL); 
if (var != NULL)
printk("leaked %d bytes at address %x\n", bytesLeaked, (unsigned int)var);

This code is in the init_module. I have the following questions

1. How do I determine whether the code has leaked memory? lsmod does not reveal much.
2. The tutorials on the internet only show the code in init_module and exit_module. What if I wish to do the memory allocation over a period of time after the module has been inserted but before exiting.
3. Is it possible for me to write code that leaks memory only when the user gives an instruction for it to do so e.g. can a user space program do a system call which will cause the module to leak memory?

If you need to check if a kernel module has leaked memory and your machine has x86 architecture, you can use KEDR system, it includes a memory leak detector.

KEDR does not require you to rebuild the kernel. The online docs (see "Getting Started", for example) describe how to install and use KEDR. In short, the procedure is as follows.

Installation (from source): untar source archive - cmake <...> - make - make install

Start KEDR before you load your module:

$ kedr start <name_of_the_module_to_analyze> -f leak_check.conf

Then you can load your module and work with it as usual. After you unload it, KEDR will give you a report in debugfs (usually debugfs is mounted to /sys/kernel/debug), for example:

$ cat /sys/kernel/debug/kedr_leak_check/info
Target module: "...", 
Memory allocations: 3
Possible leaks: 2
Unallocated frees: 0

The file possible_leaks from /sys/kernel/debug/kedr_leak_check/ provides information (address, size, call stack) about each leaked memory block.

Finally, you can stop KEDR (note that /sys/kernel/debug/kedr_leak_check/ will disappear):

kedr stop

If you are using a system with architecture other than x86, Kmemleak may also be helpful although it is a bit more difficult to use. You will probably need to rebuild the kernel with CONFIG_DEBUG_KMEMLEAK parameter set to 'y'. Still, Kmemleak is a very useful tool too. See Documentation/kmemleak.txt in the kernel sources for details.

1. Code leaks memory when it allocates a block of memory (such as with kmalloc()) and then loses all references to that block of memory without ever freeing it first. Your code has not done this, as you still have var in scope and pointing to your block of memory. If you add var = NULL; on the next line, then you have a bona fide memory leak.

2. And it is absolutely possible to have it so that an event in user-space triggers your kernel module to start allocating memory. I'm not sure if you can do it directly via a system call, but if you can't then there are a number of other ways to accomplish the task. You just need to pick one and implement it. Even something as simple as having a predetermined file that you touch every time you want to trigger a memory allocation should work. Though I don't see why you can't have your init_module code spawn a thread that just allocates memory periodically over time, if that is the behavior that you want.