LKML Summary Podcast

Audio: http://media.libsyn.com/media/jcm/linux_kernel_podcast_20090802.mp3

Apologies for lagging behind. Last week was pretty busy and the box hosting the podcasts got attacked by script kiddies over the weekend. Here we go with a mega update round of podcasts for your edutainment.

For the weekend of August 2nd 2009, I’m Jon Masters with a summary of today’s LKML traffic.

In today’s issue: Big Kernel Lock, Futexes are tricky, Kbuild, Ksplice, MMC, RAR, TTY, and a tux3 filesystem update.

Big Kernel Lock. Frederic Weisbecker posted some ftrace tracing patches enabling Big Kernel Lock tracing and filter regex support for doing so. Using these patches, one can monitor BKL events (presumably with an eye toward removing them over time as part of the BKL reduction efforts underway). Separately, Federic also emailed to “announce” version 2 of the reiserfs/kill-bkl tree, which one assumes benefits from his ftrace patches in isolating and removing dependencies upon the Big Kernel Lock. His posting includes some benchmarks, and a lot more detail about his work.

Futexes are tricky. Eric Dumazet posted a nice summary of an ongoing infinite loop futex bug that several folks have been seeing on their kernels recently. As Eric says, clone() provides special support for the TID of created threads, allowing one to request that an integer in user memory be updated on creation (with it’s TID), and cleared on thread death. But because this integer location is in userspace memory, we need to be careful that the kernel doesn’t keep this pointer after an execve() – since the userspace is entirely replaced with another one. The fix is straightforward (setting clear_child_tid to NULL on execve to ensure the kernel will not try to write into it afterward).

Kbuild. Robert P J Day asked again whether there was any interest in a Kbuild “maturity level” that would enable one to attribute various levels of code maturity to kernel configuration options. For example “maturity DEPRECATED”, “maturity OBSOLETE”, or even “maturity BLEEDING_EDGE”. In many ways this feels like the existing EXPERIMENTAL dependency, but it is not a dependency. Instead, this is an entirely new kind of Kbuild attribute that is not as much “just plain hacky” as the existing support for enabling EXPERIMENTAL features. Speak now, or forever hold your peace. Robert would like your opinion.

Ksplice. Tim Abbott posted a preparatory patch series that cleans up the kerne’s explicit references to sections such as .data.page_aligned, .bss.page_aligned, and .data.init_task, replacing them with macros so that they can later be renamed if compiling with GCC -ffunction-sections -fdata-sections. This is a necessary pre-requesite for ksplice getting into the upstream kernel, although, of course it also helps those who want to compile the kernel using split out sections for reasons of memory footprint optimization and removal of unwanted code, for example on embedded systems.

MMC. Pierre Ossman (outgoing MMC maintainer) posted to let everyone know about the current patches that have been lingering in his inbox. These include patches for Intel Moorsetown, an “agressive clocking framework”, “prevent dangling blockdevice from accessing stale queues”, and a number of other patches. Many of them have hints about merge suitability and the idea was clearly to provide Andrew Morton (who has previously said that he now becomes the “de facto” MMC maintainer) with some hints to help him to get going. One hopes that someone else will step up and be in a position to take over rather than having Andrew keep stewardship of yet another kernel subsystem. Separately, Pierre posted his last “git pull” request for MMC.

RAR! Ossama Othman posted a series of patches implementing support for Intel Moorsetown supported Restricted Access Regions (RAR). These are regions of physical memory that cannot be accessed by the CPU (and thus Linux) once they have been locked down using RAR. Ossama notes that didn’t want to try fine grained page level allocations to lock down these regions, but instead wanted a blunt approach using a simple allocator. He has recently also discovered the lib/genalloc.c allocator though and suggests a future version may convert to using that allocator instead of providing his own. Comments are appreciated.

TTY. As hinted previously, it looks like Greg Kroah-Hartman really was stricken with some kind of horrible bug and decided to take on TTY maintainership. He posted a patch in which he says “Clearly, I am a glutton for punishment. I’ll see if I can see Alan’s changes through to the end, otherwise I’ll be fending off a lof of bug reports for usb-serial devices.” This suggests he has reluctantly concluded he might be the best person for the job right now. The MAINTAINERS patch includes a quilt tree, which he has asked Stephen Rothwell to begin to immediately pull into linux-next. Stephen followed up to say that he would be doing just that.

Tux3. The tux3 filesystem aims to offer various write-anywhere, atomic commit, fully versioned features of the kind that one can find in other modern file system projects currently under development. It is based on tux2, which was never released (apparently due to “evil patents sighted”) and is developed by (the highly vocal) Daniel Phillips – these days largely in his spare time. There have recently been a number of postings on the tux3 mailing list, cross posted to LKML, concerning the future of the project and how more volunteers could be encouraged to help, given that Daniel is short on time himself. He has posted some janitorial projects that those interested in getting involved can look into. More generally, Ted T’so suggested that Daniel consider what exactly tux3 offers as it’s main selling points over and above other filesystems – perhaps echoing the thoughts of others who might be wondering exactly why another filesystem is needed to compete with btrfs.

In today’s miscellaneous items: Gui Jianfeng posted some followup benchmarks of Vivek Goyal’s IO scheduler based IO controller (version 7 thereof) showing even better performance figures (for fairness set to zero as before), some ALSA trivial fixes (Takashi Iwai), some Fujitsu laptop specific fixes (Jonathan Woithe), some kmemleak detected memory leak fixes in case radeon_driver_load_kms fails on startup (Xiatian Feng), some (network related) kmemleak reports from Zdenek Kabelac, an explanation of the relative support status of RTL8192SE parts vs. over Realtek network chipsets (Barlomiej Zolnierkiewicz), Roger Quadros followed up as a result of his own previous question concerning use of generic CPU GPIO pins to drive voltage regulator circuitry with a patch he had produced, a fix from Robert Richter to avoid losing samples within the ring_buffer code if a padding event is returned from ring_buffer_consume calling rb_buffer_peek (leading to rb_advance_reader() being called twice) – he also posted a fix for rb_buffer_peek itself, some block bits from Jens Axboe (described as “some minor bits”), some additional x86 fixes from Peter Anvin, version 3 of the previously featured ummunotify, a comment from Frederic Weisbecker that the “Big Kernel Lock” page on the upstream RT wiki was not writeable (which turned out to mean that anonymous writes are not allowed without creating a user account first, as he later noted in a followup message), some x86 IOAPIC simplification and bugfixes (Cyrill Gorcunov), a ctags usability fix (Stefani Seibold), a question about “problems with CONFIG_KVM_GUEST” from Ted T’so (including the exact commands that he is using to start up the qemu backed KVM guests for ext4 testing), a series of “semantic patch” changes fixing various minor readability problems (Julia Lawall), a patch moving resource counters to percpu counters (Balbir Singh), a watchdog fix (Wim Van Sebroeck – only a single fix for a specific device that needs additional interrupt handling logic), some md fixes (Neil Brown), some earlyprintk improvements for those seeking to be debugging over EHCI USB devices on x86 platforms (Jason Wessel), some XFS fixes (Felix Blyakher), a fix for the /proc/kcore reading panic (Kamezawa Hiroyuki), a new “virtio” IDs file to make assigning new IDs much easier and less error prone than it had been having them all over the kernel sources (Fernando Luis Vazquez Cao), and someone else asked about mm/linux-next releases being on the front page of kernel.org once again (Dave Young).

A security item: Ulrich Drepper pointed out an information leak in signalstack caused because the stack_t data structure was defined “before people cared much about 64-bit architectures”. It has a hole in the middle that can leak information to userspace.

In today’s announcements: Linux 2.6.31-rc5. Linus Torvalds announced Release Candidate 5 of the upstream Linux kernel, on Friday evening at 17:49 (PDT). Linus says he wanted to push this now because there are a number of fixes for regressions whereas he’s not so sure about some of the stuff still queued so he wants to get this out there first. Gene Haskett has already posted a fresh crash report before his “amanda” backup process ran, showing a “bad page state” in a tar task. Gene is seeking suggestions to track this down.

Upstart version 0.6.3. Scott James Remnant announced version 0.6.3 of upstart, which includes a bugfix for a job’s main process being terminated while it is already in a stopping state, and a number of other bug fixes. Scott strongly suggests that those distributions using 0.3 migrate to 0.6 in order to help detect and correct bugs in the code, and to benefit from various features present in newer releases of the legacy init replacement.

The latest kernel release is 2.6.31-rc5, which was released by Linus on Friday evening.

Rafael J. Wysocki posted a list of regressions introduced between 2.6.29 and 2.6.30, and also a list of regressions introduced from 2.6.30. The list shows a recent drop in unresolved regressions (co-incidental with Linus’ latest release, which was heavy on regression fixes), but there are still a number of nasty problems there. Separately, Rafael posted individual bugzilla updates.

Stephen Rothwell posted a linux-next tree for July 31st. Since Thursday, the requested OProfile tree was added, Catalin Marinas’ kmemleak tree was undropped as the build failure was resolved, and a number of other trees overall lost their build failures. With the addition of the oprofile tree, there are now 136 sub-trees in the linux-next compose. I shall discontinue notifying that the powerpc tree doesn’t build in an allyesconfig build configuration because it hasn’t done so in many months at this point.

That’s a summary of today’s Linux Kernel Mailing List traffic, for further information visit www.kernel.org. I’m Jon Masters.