"For the last release, I stated that I thought the 2.6.22.12 release would be the last one in the 2.6.22.y series. Since then, I've received a number of other patches that would be nice to have in the .22.y tree," explained Greg KH. He continued:

"So, for a while, I'll keep the 2.6.22.y tree open, doing new releases every once in a while as they accumulate. I do this, for no other than the selfish reason that I use it every day on my openSuSE 10.3 boxes as that is the kernel base that release is on :)"

Greg KH and Chris Wright have been maintaining a -stable 2.6.x.y patchset for the 2.6.x and 2.6.(x-1) kernels since March of 2005. 2.4 stable kernel maintainer Willy Tarreau has also maintained patches against the 2.6.20 branch since August of 2007, though noted that he'll switch to maintaining the stable 2.6.22 branch once Greg finishes. Adrian Bunk also continues to maintain a -stable 2.6.16 branch of the Linux kernel.

"I've just released Linux 2.4.36-pre1," announced 2.4 maintainer Willy Tarreau. He described a new feature found in the first pre-release:

"In private discussions, Solar Designer proposed to restrict the ability to map the NULL address to CAP_RAW_IO capable processes only. The idea behind this was to prevent 'normal' users from trying to exploit NULL dereferences in the kernel which have not been discovered yet. This is purely a preventive measure."

Willy added that a similar feature exists in the 2.6 kernel, "Chris Wright noted that 2.6 already has a somewhat similar feature brought by Eric Paris, which introduces a sysctl by which the admin can set the lower mappable address." He also noted that the feature can be disabled, "Alan Cox indicated that it was desirable to be able to dynamically disable the feature because some (very) rare programs map the NULL pointer to speed up their walk through linked lists by avoiding NULL pointer checks." Finally he asked for testers, "please report any breakage you would detect when enabling it. We're pretty confident that almost every applications will not see any difference since no normal application maps NULL. But it would be interesting to identify the "special" ones."

In an overwhelmingly large series of 556 patches, Joe Perches attempted to track down maintainers for a significant number of files within the Linux kernel source tree. He explained, "I grew weary of looking up the appropriate maintainer email address(es) to CC: for a patch", adding a new line format to the kernel MAINTAINERS file parsed by a new get_maintainer.pl script.

Much of the feedback was criticism of the large number of patches that flooded the inboxes of all subscribers to the Linux Kernel Mailing List. Others suggested that the information would be better extracted from Git than from source files. When Joe asked for better ideas for achieving his end goal, Alan Cox suggested, "working off the git tree as it shows who actually is making changes/updating stuff recently and why which is a major clue when tracing bugs". Chris Wright pointed out, "I think this data will easily become stale. What is the point again?" going on to add "between git (or gitweb), existing MAINTAINERS and a bit of common sense (or extra sleuthing), I never perceived a significant problem." Adrian Bunk countered, "for active kernel developers like you and me it's not a problem. But for other people it's non-trivial to always figure out who the maintainer of some part of the kernel is."

Greg KH and Chris Wright have been maintaining a -stable 2.6.x.y patchset for the 2.6.x and 2.6.(x-1) kernels since March of 2005. Thus, with the current stable release being 2.6.22, they maintain -stable patches for 2.6.22 and 2.6.21. 2.4 stable kernel maintainer Willy Tarreau noted the currently high patch rate in each of the 2.6 -stable trees and decided to maintain -stable patches against the 2.6.20 tree until things calm down. Adrian Bunk also continues to maintain a -stable 2.6.16 branch of the Linux kernel. Willy explained about his new 2.6.20 -stable patches:

"I proposed Chris and Greg to continue issuing a few more 2.6.20 releases during the time needed for 2.6.21 and 2.6.22 to show a significant drop in their patch rates, which hopefully will be just a matter of a few releases.

"My goal is *not* to do all the hard work they do, but just to backport from their patches those which are meaningful for 2.6.20. For this reason, 2.6.20 releases will always be slightly late and should not contain patches not merged in more recent releases."

With the release of the 2.6.16 Linux kernel, Adrian Bunk reiterated his previously debated intention of maintaining the 2.6.16.y kernel tree well into the future. The first 2.6.x.y release was 2.6.8.1 by Linus Torvalds [story], a quick one line fix for NFS. The idea was revisted a few months later in October of 2004 [story], but didn't actually gain momentum until March of 2005 [story] [story]. Beginning with the 2.6.11 kernel, the process was formalized with Greg KH and Chris Wright officially maintaining 2.6.x.y releases [story] until 2.6.(x+2) is released. For example, stable patches will be applied to the current 2.6.16.y kernel by Greg and Chris until 2.6.18 is released sometime well in the future.

Adrian's plan is to pick up the development of the 2.6.16.y kernel at that point, maintaining it much as the 2.4 kernel tree is is maintained [interview]. His intention is to maintain the tree as long is it is used and people contribute patches. The earlier debate on this idea was met with mixed reactions. At that time Greg KH cautioned, "the time and energy to do this for a long period of time is huge. If I were you, I would listen to the people who have and do maintain these kinds of kernels, it's not a simple job by any means."

A lengthy and interesting thread was started on the lkml by Chris Wright looking to define a centralized place to report security issues in the Linux Kernel. Chris offered his services in getting things set up, addressing his email to Linus Torvalds, Andrew Morton [interview], Alan Cox [interview] and Marcelo Tosatti [interview]. He explained that he wanted to centralize the information "to help track it, make sure things don't fall through the cracks, and make sure of timely fix and disclosure". The resulting discussion was joined by numerous members of the kernel hacking community, exposing a wide range of opinions.

Linus agreed that it sounded like a good idea, but qualified this by adding, "the _only_ requirement that I have is that there be no stupid embargo on the list. Any list with a time limit (vendor-sec) I will not have anything to do with." An embargo in this case is the time period from when a security problem is first reported to when a fix can be made public. Marcelo pointed out that a certain amount of time is necessary, "for the vendors to catch up", explaining that "it is a simple matter of synchronization". Linus again stressed his dislike for the vendor-sec mailing list suggesting that at times the length of the embargo period is often more about politics than anything else. He then added, "but in the absense of politics, I'd _happily_ have a self-imposed embargo that is limited to some reasonable timeframe (and "reasonable" is definitely counted in days, not weeks. And absolutely _not_ in months, like apparently sometimes happens on vendor-sec)." In a followup comment he clarified, "btw, the only thing I care about is the embargo on the _fix_", noting that he was comfortable if there was a need to delay publishing an explanation of the security hole so long as the fix itself was quickly released.