LKML Summary Podcast

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

I’m traveling in Tokyo, Japan between Monday and Friday this week (with a jolly 32 hours of flights in between) so am podcasting when I can. Today’s update gets us most of the way back toward being up to date.

From Tokyo, Japan, for the 4th July 2009 weekend, I’m a semi-jetlagged Jon Masters with with a summary of the weekend’s LKML traffic.

In today’s issue: Futexes, IO-MMU, Kmemleak, MM, OOM, VFAT.

Futexes. Mike Frysinger pondered aloud about futex support for architectures devoid of atomic instructions, such as is the case for the Blackfin port. He noted that existing atomic operations are implemented on Blackfin using an obvious interrupt disable/enable cycle, which could be used within futex_atomic_op_inuser() as is apparently the case for the SuperH port (via their asm/futex-irq.h header. Mike wondered why this couldn’t just be moved generically into the top level futex header, making futexes available to architectures such as Blackfin and SuperH by default.

IO-MMU and Trusted Boot. Joseph Cihula pointed out that systems using Intel TXT require that the IO-MMU be enabled in order to perform DMA operations. But the user is able to control this via kernel command line options, which can break TXT booting. Joseph had posted a patch to always force IO-MMU use in the case of TXT-enabled boot, but this was NACKed by a several others on the grounds that it intentionally goes against documented options and changes expected behavior. The current suggestion is simply to panic if the kernel is presented with incompatible TXT and IO-MMU options at boottime.

Kmemleak. Ingo Molnar followed up to an email from Catalin Marinas from last week (in which Catalin had sought advice and suggested that exiting a task with locks still held might be acceptable in the case of piped reads from the kmemleak interface, and that lockdep should not be generating a warning). Ingo understood the point Catalin was making, but re-asserted that “holding locks in user-space is almost always bad”, and that “I’ve yet to see a valid ‘need to hold this kernel lock in user-space’ case, and this does not seem to be such a case either.” Also on the subject of kmemleak, the background scanning process is now nice +10 by default, following the acceptance of another patch that Ingo Molnar signed off on at the same time. Separately Catalin posted a number of kmemleak fixes that are presumably intended for -rc3.

mm. Andrew Morton’s recent mm-of-the-moment for 2009-06-30-12-50 was dying early in boot for Valdis Kletnieks, who tracked it down to a miss-use of wake_up_interruptible in some recent reworks from Oleg Nesterov. Oleg followed up to say that he should have a fix available shortly, especially now that he is able to use the special __wake_up_parent() as an exported function.

OOM. Following up to recent discussion concerning noswap related patches triggering excessive OOM kill scenarios, and simply in reaction to the general mess that is trying to figure out exactly why an OOM occured, Kosaki Motohiro posted a “OOM analysis helper” patch series which adds a number of statistics to the output produced by the kernel on an OOM condition.

VFAT. Discussion surrounding the dual use of long and short filenames continues, with various members of the community chiming in. In part of the latest discussion, Andrew Tridgell and Jan debated a potential regression in the creation of short file names unreadable to certain devices with the latest patch series applied. Andrew suggested that the answer was actually to change the default behavior for 8.3 short names to use a Windows NT compatibility option, but that this would be a potentially incompatible behavior change requiring some further thought. Either way, the VFAT issue is still a hot one.

In today’s miscellaneous items: IO-MMU fixes for AMD (Joerg Roedel), a continued debate over extending pipe() to support NULL arguments (Changli Gao), a poll_wait call and receive callback race fix (Jiri Olsa), some late breaking parisc updates for 2.6.31 (Kyle McMartin – who notes that these were delayed as a few were being tracked down), questions about whether Core i7 frequency is working correctly (Felix von Leitner – Arjan van de Ven contends
that the person concerned should check with the output of PowerTOP to see what is actually happening), version 8 of the run-time PM framework patch for run-time power management of IO devices (Rafeal J. Wysocki), version 9 of the irqfd patch series (Gregory Haskins – fixing races, restoring DEASSIGN support, and a couple of other bugs), another version of x2APIC without interrupt remapping for KVM use (Gleb Natapov – the patch doesn’t note the previous one, but I assume it’s simply a new iteration), Firewire updates from Stefan Richter (and on that subject, Jun Koi also posted, asking where firedump and fireproxy debugging utilities had gone), even more Minix V3 related stuff from Doug Graham, and a followup from Jeff Arnold of Ksplice, Inc. clarifying some miss-conceptions about the true power of Ksplice. In this author’s opinion, too many people are jumping to conclusions concerning what Ksplice can and cannot do without reading Jeff’s excellent paper and actually trying it out for themselves.

Finally today, Daniel Mierswa posted concerning kernel command line escaping of quotation marks. It seems someone has finally gotten annoyed enough with current quote limitations to do something about it. I would finish with a discussion of the Voyager baiting over the past week, but LWN already did a pretty good job with that discussion summary.

In today’s announcements: Linux 2.6.31-rc2 (more on that in a moment). Robert P. J. Day posted announcing that he is writing a new column for Linux.com on kernel development, which is aimed mostly at newer kernel developers

The latest kernel release is 2.6.31-rc2, which was born on the 4th of July. While he was scared by the i915 updates, Linus seems otherwise fairly happy, although he does note that he will be lot stricter about patches for rc3, and he remains very concerned that folks actually report bugs, including regressions as often as they notice them. There are some concerns already with regard to various lockdep limits being exceeded in this latest kernel. Roland Dreier also noted an ext4 related lockdep problem with jbd2_handle, which Ted T’so thinks is a valid bug that needs some looking into.

Stephen Rothwell posted a linux-next tree for July 3rd. Since Thursday, the sfi tree is still dropped, the tree still fails to build in an allyesconfig powerpc build configuration, and the xfs tree gained a build failure so the version from the previous day was used instead. The total subtree count remains steady at 132 trees in today’s linux-next compose.

That’s a summary of today’s LKML traffic. For further information visit kernel.org. I’m Jon Masters.