"In user space there are many open source projects that one can
use to identify memory leaks and corruptions such as electric fence
[6], its newer fork DUMA [7], and valgrind [8]. However, for code
running in kernel context these tools are not available.
"When the problems mentioned above end up as a "kernel panic" as
they often do, there is no further ability for the engineer to
inspect the offending code other than to observe the stack trace.
Also in kernel context, a memory leak is persistent: it will remain
existent and most probably keep growing until a reboot, something
that is unacceptable.
"Kernel development allows direct access to the basic components
and resources of the operating system, but debugging is not easy as
the use of a debugger is not handy. One has to either use
additional logging or use advanced techniques such as using kernel
debuggers like kdb [2][3] and kgdb [4] or use kernel patches such
as the one provided by Catalin Marinas, described in [1]."
