The floodgates have opened. Merge window or not, the floodgates have well and truly opened now, with large number of tree updates flying around, all targeting what will someday become kernel 2.6.31. The record, as usual, goes to the village of Ingo Molnar, who managed to send out 27 unique tree branch pull requests yesterday. Most of these were x86 and scheduler related (including removal of MEMORY_HOTPLUG_RESERVE code, and a new "glove box" BIOS sandbox environment from Peter Anvin), but he did also find some time to push IRQ updates (including more 32/64 merging), and a new version of the performance counters patch series, for good measure. Ingo's locking branch includes a new "atomic_dec_and_mutex_lock" API function call, though there are probably others hiding in there amongst the huge number of patches.
Ingo's "urgent" x86 topic branch pull request came accompanying a remark that Linus might "have a look whether in hindsight you'd have preferred to have any of these upstream sooner, in the final week of .30. We generally only send you lots-of-boxes-affected fixes after the final -rc". Linus was overwhelming positive about the .30 experience, only really moaning that new CONFIG options should never default to 'y' - which had been the case (he cited, amongst other things, CONFIG_FTRACE) - and even eliciting a "Good job", which is high praise.
Other tree pull requests today included ext4 updates from Ted T'so (he noted that most of these have been in testing since at least 30-rc8 if not a lot before that point), IDE updates (part 1) from Bartlomiej Zolnierkiewicz, KVM updates (Avi Kivity) - including MSI (Message Signalled Interrupts) support, a rework of the interrupt code, improved smp performance, and architecture code updates - Super-H updates (Paul Mundt), GFS2 updates (Steven Whitehouse), a first round of block patches (Jens Axboe), jfs (Dave Kleikamp), some libata quickies (Jezz Garzik), and Brtfs updates (Chris Mason). Chris wanrs that the Btrfs update includes a forward rolling format change that older kernels won't be able to read - conversion is automatic on mount. To avoid locking testers into 2.6.31-rc, Chris is going to maintain a stable branch of btrfs changes for 2.6.30, to give a stable kernel option too.
James Morris did get the memo about 2.6.30. In announcing what would be in the security-testing tree for 2.6.31, he remarked that "Linus has asked people to test 2.6.30 for a week before opening the merge window" - suggesting he will be formally requesting a pull later. In his tree, there are a number of IMA, SELinux, TOMOYO, and TPM fixes, as one might expect, including Christoph Lameter's "use mmap_min_addr independently of security models" patches that were under such heavy discussion upstream last week.
Early SLAB allocation (replacing bootmem). Pekka J Enberg has been busy today. He posted a new tree implementing early SLAB availability, then updated it several times (v2, v3), while also beginning to post what are likely to be many small patch updates replacing use of bootmem with direct SLAB allocated memory. For example, one patch substituted several calls to alloc_bootmem_cpumask_var with calls to alloc_cpu_var. On a slight tangent, Pekka debated with Christoph Lameter about disabling SLUB debugging if it increases the minimum page order - instead logging that this was disabled, for exmaple to the kernel global ring buffer. Christoph is concerned that this leads to a situation in which some slabs have debug on and some do not, which is, needless to say, a confusing circumstance to find oneself in.
Userspace notification of filesystem errors. Denis Karpov posted version 2 of his patchset intended to add notification of certain filesystem errors, via the use of sysfs and uevents. The use case cited was that of a hand-held device containing large FAT volumes on MMC that are error prone. Rather than performing a read-only remount on error, Denis wants userland to be able to react to this and "do something about fixing the FS". The fact that he works for Nokia, and that they make embedded Linux devices, suggests that this is a common enough problem for their users. There are almost certainly many more.
fsnotify. On a similar filesystem notification note, Eric Paris posted a pull request for Linus to take a new filesystem notification implementation called fsnotify that reimplements inotify-user and dnotify on top of a generic infrastructure. Eric says that he will work with Al (Viro) over the coming days in order to find a way to merge the last in the kernel user of inotify (audit) so that "we can [start] to kick that old inotify code out. Big winner here, new extensible notification framework and we shrink struct inode".
Stephen Rothwell posted a linux-next tree for June 11th. Since Wednesday, the Voyager tree has been removed (while it is being reorganized) - no doubt James will be devastated, a number of (Ingo) sub-trees have been replaced with "tip", and the tree continues to fail to build in an allyesconfig build configuration for powerpc. There were a number of other conflicts and build issues logged in todays posting. The total tree count (following the re-organization of Ingo's tip bits) falls to 129.