Coming to you from Cambridge, Massachusetts, for the 2009 US Memorial Day Weekend Holiday, I'm Jon Masters with a summary of the weekend's LKML traffic.
Thanks for bearing with me while I got this update out. Being in Canada visiting with Andrew Hutton (of the Linux Symposium) over the weekend meant a delay in making the recording. A summary of Tuesday's LKML traffic is coming, once your author has had his (very) early morning coffee.
In today's issue: dynamic performance counters, kprobe-based event tracing, OOM killer, page sanitization, 16-bit stack corruption on NMI, DO_ONCE, CPU hotplug, and a new kernel release.
Dynamic performance counters. Paul Mackerras posted version two of a patch series intended to enable dynamic perf_counter_context struct allocation for tasks. The main reason for the patch series is to allow a perf_counter_context struct to be transfered from one task to another when doing a lazy PMU (Performance Management Unit) switch enabled in a later patch. The patch also helps trim some weight from task_struct and allows the performance counter information to outlive the task itself. On the subject of performance counters, Peter Zijlstra let loose with perf-counter updates, sending out three different updates.
Kprobe-based event tracing. Masami Hiramatsu posted a 6 part patch series implementing version 7 of his kprobe-based event tracer. Unlike the existing events tracer (which uses tracepoints) and the existing function tracer, the kprobe-based event tracer uses dynamically inserted kprobes to trace almost anywhere in the kernel - including inside functions. The patch adds a new "kprobe_events" tracing entry.
OOM killer. Christoph Lameter put out a patch as a followup to his previous message thread concerning misleading OOM messages. Since "OOM" typically doesn't actually mean "out of memory", but more that the VM page reclaim algorithm was unable to free up sufficient memory for an allocation, Christoph adds a warning when all of swap becomes full and further swapping will fail, then removes existing OOM messages, replacing them with "memory reclaim failure" messages instead.
Page sanitization. Larry H. posted a patch implementing page sanitization. This patch, which adds the sanitize_mem kernel command line option will ensure that the page allocator performs sanitization of all memory pages upon release. It is largely based off the same feature in the PaX project and the original PG_sensitive patch which allowed fine-grained marking of pages.
16-bit stack corruption on NMI. Alexander van Heukelum noticed that the NMI handler was changing the %esp register on return to tasks with a 16-bit stack. He posted a patch that he has also requested be immediately applied to the stable kernel series since it affects 2.6.28 and probably earlier.
DO_ONCE. Joe Perches posted a patch series intended to generalize the functionality of the printk_once macro into calling any code path exactly once. The implementation is fairly obvious.
CPU hotplug. Venkatesh Pallipadi posted a patch series forcing offlined CPUs to enter the deepest C-state via the use of mwait loop rather than calling hlt. As listeners may be aware, recent Intel chips implement mwait as a means for the CPU to block on a memory address changing, which is already long since used to great power efficiency gain by the idle loop. Due to an oversight, this was not the case for offlined CPUs.
In today's announcements: Thomas Gleixner announced versions 126.96.36.199-rt15 and 188.8.131.52-rt16 of the RT patchset. These relatively minor update include a conflict-free rebase to 184.108.40.206, some futex updates from Thomas and Darren Hart, and a loadavg bug fix on 64-bit.
The latest kernel release is 2.6.30-rc7, which was released by Linus on Saturday evening. As he points out in his announce email, 90% of the patch is one new driver (for a Cisco PCI-Express FCoE HBA SCSI device). Although there is very little churn in the latest patch, Linus does still expect to do an rc8. Tejun Heo has already posted a patch removing the remap percpu allocator from rc7 since a subtle bug in the current implementation cannot easily be fixed without making substantial changes prior to 2.6.30 final.
Rafael J. Wysocki followed up to Linus' announcement with a list of known regressions in 2.6.30-rc7, including bug numbers for the upstream kernel.org bugzilla database instance. A total of 37 regressions are cited for rc7 with 35 marked as "pending" and 28 marked as being "unresolved".
Stephen Rothwell posted a linux-next tree for May 22nd. Since Thursday, two new trees were added - reiserfs-bkl and fsnotify, all the -tip trees were joined together (except the x86 tree) and the vfs tree has moved up with all the other fs-related trees. There is still a problem with powerpc allyesconfig, but the futex issue previously affecting ppc is now fixed correctly. The VFS tree gained a conflict against the reiserfs-bkl tree, the security-testing tree gained a conflict against Linus' tree, the tracing tree gained 2 conflicts against the net tree, a problem causing commit was reverted from the v4l-dvb tree, and the net tree was remerged again at the end of the compose in order to pick up a warning fix possibly affecting runtime trace.
Stephen Rothwell posted a linux-next tree for May 25th. Since Friday, the powerpc allyesconfig build continues to fail, the block tree lost 2 conflicts (but gained 2 build failures - two for two - due to interactions with the device-mapper kernel tree). Stephen added two patches for that. He also added a build failure patch for the md tree. The security-testing tree lost its conflict, the tip-core tree lost its conflict, and the tracing tree gained a conflict against the block tree. The total tree count is now up to 140.
That's a summary of the weekend's LKML traffic. For further information visit kernel.org. I'm Jon Masters.