"It's been two weeks rather than the usual one, because we've been hunting a really annoying VM regression that not a lot of people seem to have seen, but I didn't want to release an -rc4 with it," began Linux creator Linus Torvalds, announcing the 2.6.34-rc4 Linux kernel. He explained, "we had the choice of either reverting all the anon-vma scalability improvements, or finding out exactly what caused the regression and fixing it. And we got pretty close to the point where I was going to just revert it all." Linus continued:
"Absolutely _huge_ kudos to Borislav Petkov who reported the problem and was able to not just reliably reproduce it, but also test new patches to try to narrow things down at a moments notice. The thing took ten days of emails flying back and forth, and Borislav was there all the time, day and night, through several patches that tried to fix it (several real bugs, but not the one he hit) and lots of patches to just add instrumentation to get us nearer to the cause of the problem. And finally, today, confirmation that we actually nailed the problem. So if anybody has been seeing a oops (or sometimes a GP fault) in page_referenced(), that should be gone now."
As for the rest of the changes, Linus noted, "the bulk of the changes come from drivers - a new network driver (cxgb4), but also updates to the radeon and nouveau drivers. And then there is the random updates everywhere." Read on for the full changelog.
"The _real_ bug is clearly in the hardware design that allows you to brick those things without apparently even having a lock bit. I'm hoping Intel doesn't treat this as just a software bug. Some hw designer should be thinking hard about which orifice they put their head up in."
"The patches most people hopefully care about tend to be small details," noted Linus Torvalds, announcing the 2.6.27-rc6 kernel. He continued, "and so more regressions should hopefully be closed now, some by just reverting the commits that caused breakage. I don't think anything special merits explicit comment, but you can get a flavor for things by scanning the appended shortlog." Earlier in the announcement email, Linus did note some specifics about which drivers caused the bulk of the patch:
"Same old deal - except it's been almost two weeks since -rc5. That said, the diff is actually about the same size, so I guess that means things are calming down. Most of the diff (bulk-wise) is updates to the new gspca (standard USB webcam) driver, although some of it is also removal of the dead miropcm20* driver."
Linus Torvalds announced the 2.6.27-rc5 Linux Kernel, noting that his "weekly releases" tend to happen every eight days, adding, "the bulk of it is all config updates, and with arm and powerpc leading the pack." Linus continued:
"While the config updates amount to about three quarters of the diff, and if you don't use a rename-aware diff the blackfin include file movement pretty much accounts for the rest, hidden behind all those trivial (but bulky) changes are a lot of small changes that hopefully fix a number of regressions.
"The most exciting (well, for me personally - my life is apparently too boring for words) was how we had some stack overflows that totally corrupted some basic thread data structures. That's exciting because we haven't had those in a long time. The cause turned out to be a somewhat overly optimistic increase in the maximum NR_CPUS value, but it also caused some introspection about our stack usage in general. Including things like a patch to gcc to fix insane stack usage for vararg functions on x86-64. But that one would only hit anybody who was a bit too adventurous and selected the big 4096 CPU configuration. The rest of the regressions fixed are a bit more pedestrian."
"Another week, another -rc," began Linus Torvalds, announcing the 2.6.27-rc4 Linux kernel, continuing, "this time the diffstat is almost totally dominated by the addition of the musb driver that drives the MUSB and TUSB controllers integrated into omap2430 and davinci. That, together with the removal of the auerswald USB driver (replaced by libusb version) is more than half of the bulk of the patch, and obviously most users won't ever notice." Linus added:
"Apart from those bulky USB updates, there's some arch updates (blackfin and ia64), network and input driver updates, and an XFS and UBIFS update. The rest is mostly random stuff all over, probably best described by the appended shortlog. A number of regressions should be off the table, but more remain..."
"The C standard will eventually support concurrency (they are working on it), and it will almost inevitably be a horrible pile of stinking sh*t, and we'll continue to use the gcc inline asms instead, but then the gcc people will ignore our complaints when they break the compiler, and say that we should use the stinking pile-of-sh*t ones that are built in.
"The delta cache was really a huge hack that just turned out rather successful. It's been hacked on further since (to do some half-way reasonable replacement with _another_ hack by adding an LRU on top of it), but it really is very hacky indeed."
"Things really _have_ calmed down, and hopefully we've also resolved a lot of the regressions in -rc3," began Linus Torvalds, announcing the 2.6.27-rc3 Linux kernel. He noted that much of the patch size was from the inclusion of the new ath9k wireless driver, with much of the rest of the patch size due to the renaming of many arch include files in the ARM, AVR32 and m68lnommu architectures. Linus continued:
"All the small changes are where the regression fixes are, and other random improvements. And they're all over. The ShortLog (appended) probably gives a taste of it."
"The default value should be 'off', unless it's _needed_ by people. Have you guys looked at the size of the kernel lately? Bloat is bloat. Just because it's conditional is not an excuse."
"So it's been a week since -rc1, and -rc2 is out there," began Linux creator Linus Torvalds, announcing the 2.6.27-rc2 Linux kernel. He noted, "there's a lot of random changes in there, and I'm hoping we're starting to calm down, but one particular _kind_ of random change is probably worth pointing out explicitly due to the things it can result in: the fact that a number of architectures ended up using the 'lull' after -rc1 (hah!) to do the 'include/asm-xyz' => 'arch/xyz/include/asm' renames." Linus explained that for people actively developing and merging code with git, "be aware that we've recently had more renames than the rename detection limit in git defaults to, and as a result, if you have a rename<->data change conflict, you may want to increase the default limit." Linus noted that developers with sufficient ram can set "renamelimit=0" to completely disable the limit, and others can set it to a high value such as 5,000, "the default limit is pretty low just to not cause problems for people who have less memory in their machines than kernel developers tend to have..."
Linus continued, "the dirstat (with rename detection on, so as to not show the movement as huge changes) is fairly usual, with most of the changes in drivers, along with an ext4 and xfs update making 'fs' show up pretty high too". He added:
"The shortlog is still a tad too big to make it on the list (again, as usual - normally I end up posting shortlogs for -rc3 and later when they become more manageable) but let me just say that it isn't really all that interesting. Theres' a lot of small changes here, but nothing that makes you go 'Wow!'. Not that there _should_ be anything like that in -rc2, of course, so I'm not complaining."
"I do think 'next' as it is has a few issues that either need to be fixed (unlikely - it's not the point of next) or just need to be aired as issues and understood," noted Linus Torvalds about the linux-next development tree, originally designed as a way to get subsystem maintainers more involved in managing merge conflicts. Linus continued, "I don't think anybody wants it to go away. The question in my mind is more along the way of how/whether it should be changed. There was some bickering about patches that weren't there, and some about how _partial_ series were there but then the finishing touches broke things."
He listed his two primary concerns as, "I don't think it does 'quality control', and I think that's pretty fundamental," and, "I don't think the 'next' thing works as well for the occasional developer that just has a few patches pending as it works for subsystem maintainers that are used to it." Linus continued, "I don't think either of the above issues is a 'problem' - I just think they should be acknowledged. I think 'next' is a good way for the big subsystem developers to be able to see problems early, but I really hope that nobody will _ever_ see next as a 'that's the way into Linus' tree', because for the above two reasons I do not think it can really work that way." Andrew Morton noted, "a lot of the bugs which hit your tree would have been quickly found in linux-next too," then added, "but it's all shuffling deckchairs, really. Are we actually merging better code as a reasult of all of this? Are we being more careful and reviewing better and testing better? Don't think so."
"If a reporter doesn't respond to say 'it's still open', it needs to be closed. It doesn't matter one whit whether there has been developer action on it or not. We cannot keep old reports open - it's a total waste for developers to even _look_ at anything that is more than roughly a month old and hasn't been verified to be still be an issue."
"It's two weeks (and one day), and the merge window is over," began Linus Torvalds, announcing the 2.6.27-rc1 kernel. He continued, "finally. I don't know why, but this one really did feel pretty dang busy. And the size of the -rc1 patch bears that out - at 12MB, it's about 50% bigger than 26-rc1 (but not that much bigger than 24/25-rc1, so it's not like it's anything unheard of)." He reflected, "the pure size of the -rc's _is_ making me a bit nervous, though. Sure, it means that we are good at merging it all, but I have to say that I sometimes wonder if we don't merge too much in one go, and even our current (fairly short) release cycle is actually too big." As for the actual changes, Linus explained:
"Much of -rc1 was in linux-next, but certainly not everything. We'll see how that whole thing ends up evolving - it certainly didn't solve all problems, and there was some bickering about things that weren't there (and some things that mostly were ;), but maybe it helped. There's a ton of new stuff in there, but at least personally the interesting things are the BKL pushdown and perhaps the introduction of the lockless get_user_pages_fast(). The build system also got updated to allow moving the architecture include files ('include/asm-xyz') into the architecture subdirectories ('arch/xyz/include/asm'), and sparc seems to have taken advantage of that already."
Other changes Linus highlighted included merging the UBI filesystem, as well as, "tracing, firmware loading, continued x86 arch merging, and moving more code to generic support (unified generic IPI handling, coherent dma memory allocation, show_mem etc). Bootmem rewrites. [And] some support for further scalability (ie 4k cpu cores)."
"Looking at the code it's apparently because I'm not an optimistic enough dad. But hey, if you had three pre-teenage girls, you might not be all that optimistic either."
In an announcement for the 18.104.22.168 stable kernel, Greg KH noted, "it contains a number of assorted bugfixes all over the tree. And once again, any users of the 2.6.25 kernel series are STRONGLY encouraged to upgrade to this release." The emphasis on the word strongly led to a lengthy discussion about how security fixes are handled in the Linux Kernel. Linus Torvalds replied, "I personally consider security bugs to be just 'normal bugs'. I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special." Later in the thread he went on to explain, "one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior. It makes 'heroes' out of security people, as if the people who don't just fix normal bugs aren't as important. In fact, all the boring normal bugs are _way_ more important, just because there's a lot more of them. I don't think some spectacular security hole should be glorified or cared about as being any more 'special' than a random spectacular crash due to bad locking."
Theodore T'so pointed out that other developers had different beliefs about disclosure than Linus and referred to mailing lists such as the private security@ list described in the SecurityBugs documentation, originally created in early 2005. He then described Linus' stance, "if Linus finds out about a security bug, he will fix it and check it into the public git repository right away. But he's very honest in telling you that is what he will do --- so you can choose whether or not to include him in any disclosures that you might choose to make." Regarding whether Full Disclosure is the best policy, Ted highlighted the fact that the debate has been going on for several decades, "it is clear that we're not going settle this debate now, and certainly not on the Linux Kernel Mailing List." Later in the discussion, Linus offered a succinct summary of his viewpoint, "my responsibility is to do a good job. And not pander to the people who want to turn security into a media circus."