Upstream Stable Kernel Updates
As soon as a new upstream kernel is released by Linus, a related 2.6.x.y stable maintenance tree is established to deliver updates for that released kernel. This new stable maintenance tree will be maintained until the next upstream kernel is released, unless the kernel has been designated for long-term support by the kernel community. These trees are maintained by Greg Kroah-Hartman. The kernels currently designated for long-term support are 2.6.27 and 2.6.32.
There is a git repo for each stable kernel, and they are listed on git.kernel.org as linux/kernel/git/stable/linux-2.6.*.y.git repos.
There is a combined repo with a branch for each stable version which is periodically sync'd with the individual stable repos. This repo is here:
The repo containing patches queued for stable kernels can be found here, you should check here to see whether a patch is already queued before submitting it to stable:
Getting Fixes into upstream stable
Any fix to a released upstream kernel which is of general interest should be submitted for possible inclusion in the upstream stable tree.
There is a documentation file on the upstream stable process which can be found in the Linux tree under Documentation/stable_kernel_rules.txt. The rules for acceptance of patches are similar to those for SRU acceptance in the Ubuntu kernel (below). Though in practice, the rules are sometimes relaxed.
When trying to get a fix into upstream stable, determine first whether the patch has already been submitted to upstream stable for consideration. Check the upstream stable repo(s) and the stable-queue repo (information above). When an author or subsystem maintainer determines that a patch submitted to Linus for the mainline kernel should also be considered for stable updates, they will add the following line to the signed-off-by section of the patch, will cause it to be submitted to the upstream stable maintainer for inclusion in the currently maintained stable tree.
Cc: email@example.com Signed-off-by: ...
If a patch has been CC'd to stable, then there is no need to resubmit it. If you are proposing inclusion of such a patch for Ubuntu, please state that it has been submitted for stable in the bug report and email to the ubuntu-kernel-team.
Fixes in Linus's mainline tree but not in upstream stable
If the patch is already in Linus's tree, but has not been sent to stable, it can be sent to the stable mail address. When sending patches, you should CC the subsystem maintainer (and all those that have been in the signed-off-by section). The mail must contain a quick explanation of why this meets the stable kernel rules. Generally the reason a patch qualifies is that it has been proven to fix an observed (not theoretical) bug. Depending on the patch, it might be a good idea to contact the subsystem maintainer on the subject and get his or her agreement in advance.
Different fixes than upstream
There are cases where a fix will be different from the patch submitted to the upstream tree. This can be because the patch no longer applies cleanly to an older kernel and requires some changes, or because the patch is a fix that is not required due to redesign of a subsystem. In these cases the backported or specially crafted patch is sent to firstname.lastname@example.org directly, as described above. The subsystem maintainer MUST be copied, and it is strongly suggested that you contact the subsystem maintainer first, and perhaps ask them to propose the fix for inclusion in upstream stable. Your mail must clearly explain why your fix is done the way it is, or the patch could be ignored.
Hinting pre-requisite patches
As a new addition to the known "Cc: email@example.com" line, it is possible to give hints about any patches that are required for the stable patch to work correctly. The following example, taken from the stable_kernel_rules.txt file, shows the signed-off-by section in such a case:
Cc: <firstname.lastname@example.org> # .32.x: a1f84a3: sched: Check for idle Cc: <email@example.com> # .32.x: 1b9508f: sched: Rate-limit newidle Cc: <firstname.lastname@example.org> # .32.x: fd21073: sched: Fix affinity logic Cc: <email@example.com> # .32.x Signed-off-by: Ingo Molnar <firstname.lastname@example.org>
Patches will be picked in the order they appear, so a1f84a3 will be the first and fd21073 the last (before the patch this is contained is applied).