Orange Pi5 kernel

^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   1) Kernel Memory Leak Detector
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   2) ===========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   3) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   4) Kmemleak provides a way of detecting possible kernel memory leaks in a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   5) way similar to a `tracing garbage collector
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   6) <https://en.wikipedia.org/wiki/Tracing_garbage_collection>`_,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   7) with the difference that the orphan objects are not freed but only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   8) reported via /sys/kernel/debug/kmemleak. A similar method is used by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   9) Valgrind tool (``memcheck --leak-check``) to detect the memory leaks in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  10) user-space applications.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  11) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  12) Usage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  13) -----
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  14) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  15) CONFIG_DEBUG_KMEMLEAK in "Kernel hacking" has to be enabled. A kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  16) thread scans the memory every 10 minutes (by default) and prints the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  17) number of new unreferenced objects found. If the ``debugfs`` isn't already
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  18) mounted, mount with::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  19) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  20)   # mount -t debugfs nodev /sys/kernel/debug/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  21) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  22) To display the details of all the possible scanned memory leaks::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  23) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  24)   # cat /sys/kernel/debug/kmemleak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  25) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  26) To trigger an intermediate memory scan::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  27) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  28)   # echo scan > /sys/kernel/debug/kmemleak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  29) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  30) To clear the list of all current possible memory leaks::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  31) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  32)   # echo clear > /sys/kernel/debug/kmemleak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  33) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  34) New leaks will then come up upon reading ``/sys/kernel/debug/kmemleak``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  35) again.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  36) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  37) Note that the orphan objects are listed in the order they were allocated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  38) and one object at the beginning of the list may cause other subsequent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  39) objects to be reported as orphan.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  40) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  41) Memory scanning parameters can be modified at run-time by writing to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  42) ``/sys/kernel/debug/kmemleak`` file. The following parameters are supported:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  43) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  44) - off
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  45)     disable kmemleak (irreversible)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  46) - stack=on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  47)     enable the task stacks scanning (default)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  48) - stack=off
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  49)     disable the tasks stacks scanning
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  50) - scan=on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  51)     start the automatic memory scanning thread (default)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  52) - scan=off
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  53)     stop the automatic memory scanning thread
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  54) - scan=<secs>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  55)     set the automatic memory scanning period in seconds
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  56)     (default 600, 0 to stop the automatic scanning)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  57) - scan
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  58)     trigger a memory scan
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  59) - clear
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  60)     clear list of current memory leak suspects, done by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  61)     marking all current reported unreferenced objects grey,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  62)     or free all kmemleak objects if kmemleak has been disabled.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  63) - dump=<addr>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  64)     dump information about the object found at <addr>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  65) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  66) Kmemleak can also be disabled at boot-time by passing ``kmemleak=off`` on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  67) the kernel command line.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  68) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  69) Memory may be allocated or freed before kmemleak is initialised and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  70) these actions are stored in an early log buffer. The size of this buffer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  71) is configured via the CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE option.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  72) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  73) If CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF are enabled, the kmemleak is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  74) disabled by default. Passing ``kmemleak=on`` on the kernel command
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  75) line enables the function. 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  76) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  77) If you are getting errors like "Error while writing to stdout" or "write_loop:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  78) Invalid argument", make sure kmemleak is properly enabled.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  79) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  80) Basic Algorithm
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  81) ---------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  82) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  83) The memory allocations via :c:func:`kmalloc`, :c:func:`vmalloc`,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  84) :c:func:`kmem_cache_alloc` and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  85) friends are traced and the pointers, together with additional
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  86) information like size and stack trace, are stored in a rbtree.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  87) The corresponding freeing function calls are tracked and the pointers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  88) removed from the kmemleak data structures.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  89) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  90) An allocated block of memory is considered orphan if no pointer to its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  91) start address or to any location inside the block can be found by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  92) scanning the memory (including saved registers). This means that there
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  93) might be no way for the kernel to pass the address of the allocated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  94) block to a freeing function and therefore the block is considered a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  95) memory leak.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  96) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  97) The scanning algorithm steps:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  98) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  99)   1. mark all objects as white (remaining white objects will later be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100)      considered orphan)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101)   2. scan the memory starting with the data section and stacks, checking
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)      the values against the addresses stored in the rbtree. If
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103)      a pointer to a white object is found, the object is added to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104)      gray list
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)   3. scan the gray objects for matching addresses (some white objects
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)      can become gray and added at the end of the gray list) until the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107)      gray set is finished
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108)   4. the remaining white objects are considered orphan and reported via
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109)      /sys/kernel/debug/kmemleak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) Some allocated memory blocks have pointers stored in the kernel's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) internal data structures and they cannot be detected as orphans. To
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) avoid this, kmemleak can also store the number of values pointing to an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) address inside the block address range that need to be found so that the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) block is not considered a leak. One example is __vmalloc().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) Testing specific sections with kmemleak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) ---------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) Upon initial bootup your /sys/kernel/debug/kmemleak output page may be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) quite extensive. This can also be the case if you have very buggy code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) when doing development. To work around these situations you can use the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) 'clear' command to clear all reported unreferenced objects from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) /sys/kernel/debug/kmemleak output. By issuing a 'scan' after a 'clear'
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) you can find new unreferenced objects; this should help with testing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) specific sections of code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) To test a critical section on demand with a clean kmemleak do::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)   # echo clear > /sys/kernel/debug/kmemleak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131)   ... test your kernel or modules ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132)   # echo scan > /sys/kernel/debug/kmemleak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) Then as usual to get your report with::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136)   # cat /sys/kernel/debug/kmemleak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) Freeing kmemleak internal objects
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) ---------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) To allow access to previously found memory leaks after kmemleak has been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) disabled by the user or due to an fatal error, internal kmemleak objects
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) won't be freed when kmemleak is disabled, and those objects may occupy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) a large part of physical memory.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) In this situation, you may reclaim memory with::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)   # echo clear > /sys/kernel/debug/kmemleak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) Kmemleak API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) ------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) See the include/linux/kmemleak.h header for the functions prototype.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) - ``kmemleak_init``		 - initialize kmemleak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) - ``kmemleak_alloc``		 - notify of a memory block allocation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) - ``kmemleak_alloc_percpu``	 - notify of a percpu memory block allocation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) - ``kmemleak_vmalloc``		 - notify of a vmalloc() memory allocation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) - ``kmemleak_free``		 - notify of a memory block freeing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) - ``kmemleak_free_part``	 - notify of a partial memory block freeing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) - ``kmemleak_free_percpu``	 - notify of a percpu memory block freeing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) - ``kmemleak_update_trace``	 - update object allocation stack trace
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) - ``kmemleak_not_leak``	 - mark an object as not a leak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) - ``kmemleak_ignore``		 - do not scan or report an object as leak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) - ``kmemleak_scan_area``	 - add scan areas inside a memory block
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) - ``kmemleak_no_scan``	 - do not scan a memory block
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) - ``kmemleak_erase``		 - erase an old value in a pointer variable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) - ``kmemleak_alloc_recursive`` - as kmemleak_alloc but checks the recursiveness
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) - ``kmemleak_free_recursive``	 - as kmemleak_free but checks the recursiveness
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) The following functions take a physical address as the object pointer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) and only perform the corresponding action if the address has a lowmem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) mapping:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) - ``kmemleak_alloc_phys``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) - ``kmemleak_free_part_phys``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) - ``kmemleak_not_leak_phys``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) - ``kmemleak_ignore_phys``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) Dealing with false positives/negatives
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) --------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) The false negatives are real memory leaks (orphan objects) but not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) reported by kmemleak because values found during the memory scanning
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) point to such objects. To reduce the number of false negatives, kmemleak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) provides the kmemleak_ignore, kmemleak_scan_area, kmemleak_no_scan and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) kmemleak_erase functions (see above). The task stacks also increase the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) amount of false negatives and their scanning is not enabled by default.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) The false positives are objects wrongly reported as being memory leaks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) (orphan). For objects known not to be leaks, kmemleak provides the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) kmemleak_not_leak function. The kmemleak_ignore could also be used if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) the memory block is known not to contain other pointers and it will no
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) longer be scanned.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) Some of the reported leaks are only transient, especially on SMP
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) systems, because of pointers temporarily stored in CPU registers or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) stacks. Kmemleak defines MSECS_MIN_AGE (defaulting to 1000) representing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) the minimum age of an object to be reported as a memory leak.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) Limitations and Drawbacks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) -------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) The main drawback is the reduced performance of memory allocation and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) freeing. To avoid other penalties, the memory scanning is only performed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) when the /sys/kernel/debug/kmemleak file is read. Anyway, this tool is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) intended for debugging purposes where the performance might not be the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) most important requirement.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) To keep the algorithm simple, kmemleak scans for values pointing to any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) address inside a block's address range. This may lead to an increased
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) number of false negatives. However, it is likely that a real memory leak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) will eventually become visible.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) Another source of false negatives is the data stored in non-pointer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) values. In a future version, kmemleak could only scan the pointer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) members in the allocated structures. This feature would solve many of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) the false negative cases described above.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) The tool can report false positives. These are cases where an allocated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) block doesn't need to be freed (some cases in the init_call functions),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) the pointer is calculated by other methods than the usual container_of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) macro or the pointer is stored in a location not scanned by kmemleak.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) Page allocations and ioremap are not tracked.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) Testing with kmemleak-test
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) --------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) To check if you have all set up to use kmemleak, you can use the kmemleak-test
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) module, a module that deliberately leaks memory. Set CONFIG_DEBUG_KMEMLEAK_TEST
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) as module (it can't be used as built-in) and boot the kernel with kmemleak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) enabled. Load the module and perform a scan with::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235)         # modprobe kmemleak-test
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236)         # echo scan > /sys/kernel/debug/kmemleak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) Note that the you may not get results instantly or on the first scanning. When
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) kmemleak gets results, it'll log ``kmemleak: <count of leaks> new suspected
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) memory leaks``. Then read the file to see then::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242)         # cat /sys/kernel/debug/kmemleak
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243)         unreferenced object 0xffff89862ca702e8 (size 32):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244)           comm "modprobe", pid 2088, jiffies 4294680594 (age 375.486s)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245)           hex dump (first 32 bytes):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246)             6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247)             6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  kkkkkkkkkkkkkkk.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)           backtrace:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249)             [<00000000e0a73ec7>] 0xffffffffc01d2036
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250)             [<000000000c5d2a46>] do_one_initcall+0x41/0x1df
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251)             [<0000000046db7e0a>] do_init_module+0x55/0x200
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252)             [<00000000542b9814>] load_module+0x203c/0x2480
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253)             [<00000000c2850256>] __do_sys_finit_module+0xba/0xe0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254)             [<000000006564e7ef>] do_syscall_64+0x43/0x110
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255)             [<000000007c873fa6>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256)         ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) Removing the module with ``rmmod kmemleak_test`` should also trigger some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) kmemleak results.