[linuxkernelnewbies] kmemcheck Aiming For Mainline Inclusion | KernelTrap

[Peter Teoh]

http://kerneltrap.org/node/15912 kmemcheck Aiming For Mainline Inclusion April 4, 2008 - 10:41am Submitted by Jeremy on April 4, 2008 - 10:41am. "I skipped the public announcements for versions 5 and 6, but here is 7 :)," noted Vegard Nossum, announcing the latest release of his kmemcheck patch, currently applying against the 2.6.25-rc8 kernel. Vegard noted he is now hoping to get the patch merged into the mainline kernel during the upcoming 2.6.26 merge window. He described the patch: "kmemcheck is a patch to the linux kernel that detects use of uninitialized memory. It does this by trapping every read and write to memory that was allocated dynamically (e.g. using kmalloc()). If a memory address is read that has not previously been written to, a message is printed to the kernel log." Among the changes compared to earlier releases, v7 has undergone a lot of cleanup, some preparation has begun for an x86_64 port, error reporting stability has been improved, boot time and run time options have been added, and there have been several bug fixes. Submit to: Reddit, Digg, Slashdot, Del.icio.us, OSNews From: Vegard Nossum <[EMAIL PROTECTED]> Subject: [ANNOUNCE] kmemcheck v7 Date: Apr 4, 9:44 am 2008 Hi, I skipped the public announcements for versions 5 and 6, but here is 7 :) General description: kmemcheck is a patch to the linux kernel that detects use of uninitialized memory. It does this by trapping every read and write to memory that was allocated dynamically (e.g. using kmalloc()). If a memory address is read that has not previously been written to, a message is printed to the kernel log. Changes since v4 (rough list): - SLUB parts were broken-out into its own file to avoid cluttering the main SLUB code. - A rather lot of cleanups, including removing #ifdefs from arch code. - Some preparation in anticipation of an x86_64 port. - Make reporting safer by using a periodic timer to inspect the error queue. - Fix hang due to page flags changing too early on free(). - Fix hang due to kprobes incompatibility. - Allow CONFIG_SMP, but limit number of CPUs to 1 at run-time. - Add kmemcheck=0|1 boot option. - Add /proc/sys/kernel/kmemcheck for run-time enabling/disabling. These patches apply to Linus's v2.6.25-rc8. The latest patchset can also be found here: http://folk.uio.no/vegardno/linux/kmemcheck/ (I will try to submit this for inclusion in 2.6.26, and testing and feedback is of course very welcome!) I would like to thank the following people, who provided patches or helped in various ways: Ingo Molnar Paul McKenney Pekka Enberg Pekka Paalanen Peter Zijlstra Randy Dunlap Kind regards, Vegard Nossum -- Related links: Archive of above thread Tags: 2.6.25-rc8, 2.6.26, kmemcheck, Linux, Vegard Nossum Add new comment Printer friendly version What is it for? April 4, 2008 - 12:29pm Anonymous (not verified) What is this for? Is it something that are to be used by kernel developers in order to find bugs in the Linux kernel? reply Yes. April 4, 2008 - 1:14pm Anonymous (not verified) Yes. reply valgrind --tool=memcheck but April 4, 2008 - 2:11pm Anonymous (not verified) valgrind --tool=memcheck but for the kernel, it sounds like. reply Yes April 4, 2008 - 5:25pm Mr_Z My understanding is that it's like Rational (now IBM)'s Purify, but for the kernel. It uses the memory protection hardware to catch all accesses to dynamically allocated memory, and use them to determine which reads access bytes that have not yet been written to. Note that it differs from Purify in that it apparently only tracks dynamic allocations, and not stack or static allocations. (Yes, I realize that stack is a special case of dynamic.) I believe Purify tracks all memory accesses. This limitation seems reasonable, since nearly all the really interesting structures are dynamically allocated via kmalloc(). It's also different from valgrind (which someone else mentioned), in that valgrind actually simulates code, rather than just running it and (ab)using the memory protection hardware to catch issues. That's why valgrind is so slow. :-) Hmm... it might be amusing to try to run User Mode Linux under valgrind. That could be a hoot. -- Program Intellivision and play Space Patrol! reply "Hmm... it might be amusing April 4, 2008 - 8:29pm Anonymous (not verified) "Hmm... it might be amusing to try to run User Mode Linux under valgrind. That could be a hoot." Indeed. Though, I'd expect a world of pain :-O reply UML under valgrind is starting to work... April 7, 2008 - 2:24pm Dan Kegel (not verified) See http://bitwagon.com/valgrind+uml/ for details. reply Nifty! April 7, 2008 - 3:42pm Mr_Z I figured it ought to be possible, but I wasn't sure how much of UML's coziness with the host kernel might get in the way. Very nice! -- Program Intellivision and play Space Patrol! reply LWN article April 10, 2008 - 11:02pm flugstadp http://lwn.net/Articles/260068/ Side note: Purify and valgrind are actually two very different things: - Purify instruments the executable code with special instructions around every memory access - this means that your actual executable is changed, so it can (usually) only be used when your developing the code. And I don't know how well purify works with things like shared system libraries and so on. - valgrind can take any executable, even optimized or shared system library code and effectively executes it in a virtual machine, and tracks the state of every piece of memory. reply Ah, ok April 12, 2008 - 12:24am Mr_Z So, we basically have three separate pieces of technology here: Purify instruments, valgrind simulates, and kmemcheck uses protection faults. I was under the (mistaken) impression that Purify worked like kmemcheck, using protection faults to track memory access patterns rather than actually instrumenting the executable. Instrumenting the executable seems more problematic in general, but it works. On that count, Purify sounds a lot like Pin. Thanks for the clarification. -- Program Intellivision and play Space Patrol!