When the data corruption bug which is fixed as of 2.6.20-rc3 [story] was still being tracked down [story], it was thought that the bug, a race in shared mmap'ed page writeback, might have been in the 2.6 kernel for a very long time. It has since been determined that the bug was introduced much more recently. Nick Piggin [interview] explains, "this bug was only introduced in 2.6.19, due to a change that caused pte dirty bits to be discarded without a subsequent set_page_dirty() (nowhere else in the kernel should have done this)." Linus Torvalds noted that earlier kernels could have been affected by a less serious version of the bug:
"Actually, I think 2.6.18 may have a subtle variation on it. But that much older race would only trigger on SMP (or possibly UP with preempt). And I haven't actually thought about it that much, so I could be full of crap. But I don't see anything that protects against it: we may hold the page lock, but since the code that marks things _dirty_ doesn't necessarily always hold it, that doesn't help us. And we may hold the 'private_lock', but we drop it before we do the dirty bit clearing, and in fact on UP+PREEMPT that very dropping could cause an active preemption to take place, so.. I dunno. For older kernels? If there is a race there, it must be pretty damn hard to hit in practice (and it must have been there for a looong time), so trying to fix it is possibly as likely to cause problems as it migh to fix them."
David Miller pointed out that some of the confusion as to when the bug was actually introduced comes from the fact that the original bug was against a 2.6.18 Debian kernel. Andrew Morton [interview] explained, "that was 2.6.18+debian-added-dirty-page-tracking-patches," then went on to caution that the fix still does not address a newly reported and currently unconfirmed BerkeleyDB corruption bug, "I'll assert (and emphasise) that the cause of the alleged BerkeleyDB corruption is not known at this time. The post-2.6.19 'fix' might make it go away. But if it does, we do not know why, and it might still be there, only harder to hit."
A few hours before the new year, Linus Torvalds released the 2.6.20-rc3 Linux kernel, "in order to not get in trouble with MADR ("Mothers Against Drunk Releases") I decided to cut the 2.6.20-rc3 release early rather than wait for midnight, because it's bound to be new years _somewhere_ out there. So here's to a happy 2007 for everybody." In good humor, he noted that the new kernel would be available on all the kernel.org mirrors by the time everyone's New Years celebrations had concluded, "it's probably going to be up-to-date by the time the hangovers are mostly gone. At which point the first thing on any self-respecting geek's mind should obviously be: 'is there a new kernel release for me to try?'" Regarding the changes in the new release candidate, which include a data corruption fix [story], Linus summarized:
"The big thing at least for me personally is that nasty shared mmap corruption fix, but there's a number of other changes in here, many of them just documentation (and some media and network drivers). Shortlog and diffstat appended."
