The conclusion of the 3.6 merge window

By Jonathan Corbet
August 3, 2012

Linus closed the 3.6 merge window on August 2, a couple of days earlier than would have normally been expected. There were evidently two reasons for that: a desire to send a message to those who turn in their pull requests on the last day of the merge window, and his upcoming vacation. In the end, he only pulled a little over 300 changes since the previous merge window summary, with the result that 8,587 changes were pulled in the 3.6 merge window as a whole.

Those 300+ changes included the following:

The block I/O bandwidth controller has been reworked so that each control group has its own request list, rather than working from a single, global list. This increases the memory footprint of block I/O control groups, but makes them function in a manner much closer to the original intention when lots of requests are in flight.
A set of restrictions on the creation of hard and soft links has been added in an attempt to improve security; they should eliminate a lot of temporary file vulnerabilities.
The device mapper dm-raid module now supports RAID10 (a combination of striping and mirroring).
The list of new hardware support in 3.6 now includes OMAP DMA engines.
The filesystem freeze functionality has been reimplemented to be more robust; in-tree filesystems have been updated to use the new mechanism.

The process of stabilizing all of those changes now begins; if the usual patterns hold, the final 3.6 kernel can be expected sometime in the second half of September.

Index entries for this article
Kernel	Releases/3.6

/tmp link fixes

Posted Aug 9, 2012 10:35 UTC (Thu) by epa (subscriber, #39769) [Link] (2 responses)

The restrictions on soft and hard links are long overdue. This will eliminate hordes of vulnerabilities - perhaps 20%. Unfortunately a denial-of-service attack is still possible against software which uses predictable filenames in /tmp.

Clashes of filenames are the primary reason why directories exist; each user or each program doesn't have to worry about picking a globally unique filename because it can have its own directory isolated from the others. It's a pity this lesson, otherwise widely followed in the Unix design, was ignored when it came to picking a place for temporary files. Per-user temp directories would go further still to fixing these bugs. Yes, every single program can jump through hoops to pick a unique filename and retry if necessary; but why should it have to, when directories have already been invented?

/tmp link fixes

Posted Aug 10, 2012 7:48 UTC (Fri) by jezuch (subscriber, #52988) [Link] (1 responses)

> Per-user temp directories would go further still to fixing these bugs.

Per-process temporary directories would go even further. Are there any corner cases that make it impossible that were discussed even before I was born? ;)

/tmp link fixes

Posted Aug 13, 2012 11:46 UTC (Mon) by epa (subscriber, #39769) [Link]

Strictly per-process wouldn't work for the common case of saving a temporary file to be used by an external program.