2009/09/30 Linux Kernel Podcast
Audio: http://media.libsyn.com/media/jcm/linux_kernel_podcast_20090930.mp3
From the Embedded Linux Conference in Grenoble, France, for September 30th, 2009, I’m Jon Masters with a summary of the day’s LKML traffic.
In today’s issue: dm-ioband, robust lists, and page writeback.
dm-ioband. Vivek Goyal posted anothe round of benchmarks of the dm-ioband patches, again noting some problems with the implementation. In the latest tests, he created two ioband devices (ioband1 and ioband2) of weight 100 each on two disk partitions. On one (ioband1), he had a buffered writer do writeup and on the other he had one priority 0 reader and an increasing number of priority 4 readers, to see how bandwidth distribution worked. With vanilla CFQ the results were roughly as expected, but the results for the dm-ioband patches had violently wild swings in bandwith and were quite clearly not correctly preserving any kind of fairness whatsoever. Ryo Tsuruta promised to look into it some more.
Robust Lists. The Linux kernel uses a “robust list” pointer in the task struct task representation structure in order to keep track of userspace futex locks – providing a flexible (and also extensible) way to keep track of locks that userspace might want to play with, and also an atomic means for it to do so through system calls that internally result in list ops. The kernel needs to specially handle the case of a new address space through execve, and Anirban Sinha was concerned that the code within exit_robust_list was inefficient.
Writeback. Fengguang Wu noted that WRITE_SYNC_PLUG and priotization of bio writeback had been implemented about 5 months ago due to complaints from Linus (so it’s no longer true that all requests get ultimately treated equally no matter their sync/async status). Fengguang also posted a patch increasing the MAX_WRITEBACK_PAGES size and adjusting the writeback call stack to support larger writeback chunks. The reason for a limit is to prevent holding I_SYNC against an inode for “enormous amounts of time”.
In today’s pull requests: some ext4 patches for 2.6.32 from Ted T’so, some nilfs2 fixes from Ryusuke Konishi, and some block updates for 2.6.32-rc from Jens Axboe (mostly driver fixes, and especialy to cciss) which included DRBD. Christoph Hellwig considered including DRBD to be ill advised at this stage.
In today’s miscellaneous items: a patch adjusting percpu initialization on IA64 such that the head.S provided __cpu0_per_cpu special CPU percpu area is copied over to a generic location in the linear mapping during memory initialization from Tejun Heo, a request from Amerigo Wang that Barry Song add a signed-off-by to his Y2K38 time patch, a connector bugfix from Christian Borntraeger, ongoing discussion of Intel’s TXT (Trusted eXecution Technology) and in particular Pavel Machek’s views on removal/modification of RAM chips at runtime to usurp any protections, a note from Frederic Weisbecker that patches against 2.6.29 (in this case against at the time experimental “perf” patches for ARM) are useless at this point as too much has changed and patches need to be against 2.6.32, a note from Jens Axboe that find_busiest_group uses a lot of CPU (multiple SSD testcases), a note from Florian Weimer that the new O_NODE open flag implementation does allow one to bypass permission checks on open files within directories whose permissions change while the file descriptor is open (and so “the whole thing is a bit worrisome because it may turn file descriptor information leaks into something worse”), a virtio_ids patch from Christian Borntraeger that makes Rusty’s previous cleanups (moving all device IDs into a single file) once again compatible with userspace users of the header files by moving some includes around, a note from Berthold Gunreben (who had previously posted about ATA bus errors on resume that Tejun Heo though were due to the PSU briefly dropping power to the disk – for which Tejun provided some detailed advice on burning aforementioned PSU) that he had moved to another filesystem (JFS) and could no longer reliably reproduce what might still exist as an underlying error, an RFC patch from Kamezawa Hiroyuki adding percpu array counter support (as used e.g. in vmstat) and new array_counter_add, and array_counter_read functions, a patch from Arjan van de Ven taking advantage of GCC’s ability to determine at compile time whether certain copy_from_user buffers are correctly sized to produce a compile-time (and not runtime) warning in the case that they are not, version 2 of some CFS hard limit patches from Bharata B Rao, a note that bluetooth “is very ill in -next” from Alan Cox, an update to Linus Torvald’s alternatives based cmpxchg64 with some fixes based on some actual testing from Arjan van de Ven, a patch ensuring we always return from cpu_idle with interrupts enabled from Kevin Hilman, and a note from Russell King that Linus imposes a “one pull request per week” limit on arch maintainers like himself and so this can explain why the ARM tree has been broken recently.
In today’s security items: An x86_64 patch from Jan Beulich removing a register leak situation in which a 32-bit process could temporarily switch itself into 64-bit mode in order to get access to additional 64-bit register entries that are not normally cleared on return to 32-bit userspace.
Finally today, Pavel Machek complained about Daniel Walker’s ongoing round of checkpatch warning emails, suggesting that they were “unwelcome” in the case that patches already had many other known problems to resolve.
The latest kernel release was 2.6.32-rc1/rc2 (both the same).
Stephen Rothwell posted a linux-next tree for September 30th. Since Tuesday, his “fixes” tree contains a build fix for powerpc/kvm, the usb.current tree lost all of its conflicts, the scsi tree commit that was causing boot failures was still reverted, the drm tree gained a conflict against Linus’ tree and the usb tree lost all of its conflicts. The total subtree count remained steady at 139 trees in the latest linux-next compose.
That’s a summary of today’s Linux Kernel Mailing List traffic, for further information visit www.kernel.org. I’m Jon Masters.










