https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
Everything you ever wanted to know about Linux -stable releases
For all other submissions, choose one of the following procedures
For all other submissions, select one of the steps below.
Option 1
To have the patch automatically included in the stable tree, add the tag
Cc: stable at vger.kernel.orgin the sign-off area.
To automatically include patches in the stable tree, add Cc: stable at vger.kernel.org to the tag for the sign-off area.
Once the patch is merged it will be applied to the stable tree without anything else needing to be done by the author or subsystem maintainer.
Once the patch is merged, the author and subsystem maintainers don't have to do anything and it also applies to the stabke tree.
Option 2
After the patch has been merged to Linus’tree, send an email to
stable at vger.kernel.orgcontaining the subject of the patch, the commit ID, why you think it should be applied, and what kernel version you wish it to be applied to.
After the patch was merged into Linus's tree, the stable at vger.kernel.org should include the subject, commit ID of the patch, why you thought it should be applied, and why it should be applied to this kernel version. Please email me.
Option 3
Send the patch, after verifying that it follows the above rules, to
stable at vger.kernel.org. You must note the upstream commit ID in the changelog of your submission, as well as the kernel version you wish it to be applied to.
Once you have verified that you follow the above rules, send a patch to stable at vget.kernel.org. Be sure to include the changelog's upstream commit ID for the fix and which kernel version you are trying to apply it to.
Option 1 is strongly preferred, is the easiest and most common. Option 2 and Option 3 are more useful if the patch isn’t deemed worthy at the time it is applied to a public git tree (for instance, because it deserves more regression testing first). Option 3 is especially useful if the patch needs some special handling to apply to an older kernel (e.g., if API’s have changed in the meantime).
Option 1 is highly recommended. This is the easiest and most common. Option 2 and Option 3 are more useful when a patch is considered worthless when applied to a public git tree (for example, because it deserves more regression tests at first). Option 3 is especially useful if patch requires a lot of special handling for older kernels (for example, if the API has changed).
Note that for Option 3, if the patch deviates from the original upstream patch (for example because it had to be backported) this must be very clearly documented and justified in the patch description.
Option 3 requires that if the patch deviates from the original upstream patch (for example, if it is backported), it should be clearly documented and justified in the patch description.
The upstream commit ID must be specified with a separate line above the commit text, like this:
The upstream commit ID must be written on a separate line in the commit text. For example ::
commit <sha1> upstream.
Additionally, some patches submitted via Option 1 may have additional patch prerequisites which can be cherry-picked. This can be specified in the following format in the sign-off area:
In addition, some patches sent with Option 1 may have additional patches that are cherry-picked and required in advance. The description described in the signed-off area is as follows.
Cc: <stable at vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
Cc: <stable at vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
Cc: <stable at vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
Cc: <stable at vger.kernel.org> # 3.3.x
Signed-off-by: Ingo Molnar <mingo at elte.hu>
The tag sequence has the meaning of:
The tag sequence has the following meanings.
git cherry-pick a1f84a3
git cherry-pick 1b9508f
git cherry-pick fd21073
git cherry-pick <this commit>
Also, some patches may have kernel version prerequisites. This can be specified in the following format in the sign-off area:
In addition, some patches pre-require the kernel version. In this case, write the following in the sign-off area.
Cc: <stable at vger.kernel.org> # 3.3.x
The tag has the meaning of:
The meaning of this tag is as follows.
git cherry-pick <this commit>
For each “-stable” tree starting with the specified version.
Each "-stable" tree since the specified version.
Following the submission:
- The sender will receive an ACK when the patch has been accepted into the queue, or a NAK if the patch is rejected. This response might take a few days, according to the developer’s schedules.
--The sender receives an ACK when the patch is queued and an NAK when the patch is rejected. This reaction can take several days, depending on the developer's schedule. --If imported, the patch will be added to the -stable queue and reviewed by other developers and associated subsytem maintainers.
Review cycle
- When the -stable maintainers decide for a review cycle, the patches will be sent to the review committee, and the maintainer of the affected area of the patch (unless the submitter is the maintainer of the area) and CC: to the linux-kernel mailing list.
--- If stable maintainers determines that the review cycle, the patch will be sent with the review comittee, the maintainer of the area related to the patch (even if the submitter is the maintainer of the area), and the CC with the linux-kernel mailing list. I will. --If a patch is rejected by patch-related committees or linux kernel members, the patch will have its queue removed if there is a problem that maintainers and members are not aware of.
- At the end of the review cycle, the ACKed patches will be added to the latest -stable release, and a new -stable release will happen.
--At the end of the review cycle, ACKed patches are included in the latest -stable release and a new -stable release occurs. --The security patch is applied directly to the -stable tree from the security kernel team, without going through the normal revire cycle. Check with the kernel secutity team for this procedure.
Trees
- The queues of patches, for both completed versions and in progress versions can be found at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
--About the patch queue in the completed version and the version under development https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git --For the final, tagged releases of all stable kernels, the split versions of each version: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Review committee
- This is made up of a number of kernel developers who have volunteered for this task, and a few that haven’t.
It consists of a large number of kernel developers who volunteered for this task and a small number who did not volunteer.
Originally, it is a part of the Linux Kernel source code, so it will be treated as GPLv2 (recognition that it should be).
https://www.kernel.org/doc/html/latest/index.html
Licensing documentation
The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.
https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing