Log a kernel memory leak lookup location process __bug

Bug Description: Stress test a small project found that memory gradually decreased, 10 hours after the appearance of Oom

Bug Location Process: The entire engineering module decomposition, gradually narrowing the scope, because the whole project includes several relatively independent small modules, and the entire project using a single process multithreading model, resulting in decomposition, to pay special attention to the coupling between each other, can only gradually separate each module, Run the test (where the multi-process model is used, the positioning is faster, a complete function, placed in a process and multiple processes, the process of natural refinement of the function, positioning problems, a smaller range of the problem after a process of torture, finally positioning the problem to a small module in the project function. After repeated code review on the module, no exception was found, or even the operation of the memory request. When the code level does not find a breakthrough, the memory state is viewed again through various commands, and as the memory is viewed through the free command, it is found that there is a gradual decrease in the availability of the output for a long time, but it is overlooked that the memory consumed by the module process is viewed individually The RSS segment of the process has remained stable without significant growth. Based on the discovery of the previous step, the suspect is kernel memory leaks, view/proc/meminfo found a doubt: slab memory consumption is high, and sunreclaim slab has been increasing, at this time basically determine the kernel memory leak. The kernel memory is analyzed by Kmemleak and positioned in a function interface:

Char *wr_pr_debug_begin (U8 const *data, u32 len, char *string)
{
    int II;
    String = Kmalloc (len * 2 + 1, gfp_kernel);
    for (ii = 0; II < len; ii++)
        sprintf (&STRING[II * 2], "%02x", Data[ii]);
    String[len * 2] = 0;
    return string;
}
Char *wr_pr_debug_end (char *string)
{
    kfree (string);
    Return "";
}
void Test ()
{
    char *read = 0;
    Pr_debug ("%s rd%02x%02x%02x->%s%s\n", St->hw->name,
         i2c_addr, Reg, Length,
         wr_pr_debug_begin ( Data, length, read),
         wr_pr_debug_end (read);
}

A glance may not be easy to see what the above problems, there are kmalloc, there are kfree ah, seems to appear in pairs.
Test the basic skills of the time, familiar with the function call to the people should know that the compiler generally handle the parameters of the stack, is an advanced process, so that the execution of the parameters are generally reverse (due to the different compiler implementation, this process is not determined), This allows Kfree to run before Kmalloc, causing a bit of memory to be leaked each time it runs. Above is a debug output, temporarily commented out after the pressure test, problem solving, memory stability.

Summary: The entire positioning process is relatively simple, if the first step to look at the/proc/meminfo may be faster positioning problems (as this kernel driver is "large" to provide, think that there will be no problem, from the top point of view to find the problem, So not too concerned about the use of kernel-related memory), the cause of the memory leak is also very simple, the reason for this problem, the first writer's basic skills, but also the main reason is that the author out of the "dazzle" way to write this code, if the honest encapsulation of a debug function, It's no problem to call in normal order, and the way that each print is Kmalloc has some effect on performance. In short, basic skills are still very important, and do not control their own way of coding.