"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.
"With a lot of help from Ingo Molnar and Pekka Enberg over the last couple of weeks, we've been able to produce a new version of kmemcheck!" announced Vegard Nossum, adding, "the current version of the patch boots on real hardware, but we've seen freezes on some machines, so it's not perfect yet. (In other words, this patch is HIGHLY experimental, and run at your own risk, etc.)". He also offered a high level summary of 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."
Ingo Molnar credited the new patch with already finding 4 kernel bugs, and offered some more insights into how the patch works, and why it's useful, "it should also be made clear that not only does kmemcheck consume half of the RAM to do byte granular tracking of the other half of RAM, it's also slow, very slow, because almost every kernel-space instruction will generate a pagefault and then it will be single-stepped and it takes a debug fault as well. That's of course totally crazy, but that's also OK and it's what makes the feature so interesting and powerful."
"After recent discussions on LKML and a general dissatisfaction at the current printk() kernel-message logging interface, I've decided to write down some of the ideas for a better system," began Vegard Nossum, defining his proposed message logging API for the Linux kernel. He noted that what he was proposing was both backwards compatible with existing logging mechanisms, as well as extensible. Vegard described his proposed kprint() interfaces and their implementations, summarizing, "this scheme is obviously much more complex than the printk() is today. But at the same time, it is also much more powerful, extensible, and clearly/cleanly defined." He described one of the benefits:
"The kprint() and its log-level variants are implemented as macros in order to be able to transparently pass extra information into the main kprint() machinery. As an example, it might happen that an extra feature is added that prepends the current file and line (the __FILE__ and __LINE__ macros) to the message, but in such a way that it can be discarded at run-time, or recorded along with the messages. Additionally, this would allow the compiler to completely optimize out calls that are below a certain log-level severity level."
The proposal generated a lengthy discussion, but there was no indication as to whether or not it would be something that would ultimately be merged into the mainline kernel.
