Documentation/process/stable-kernel-rules.rst

3 Everything you ever wanted to know about Linux -stable releases
7 "-stable" tree:
9 - It or an equivalent fix must already exist in Linux mainline (upstream).
10 - It must be obviously correct and tested.
11 - It cannot be bigger than 100 lines, with context.
12 - It must follow the
13   :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
15 - It must either fix a real bug that bothers people or just add a device ID.
18   - It fixes a problem like an oops, a hang, data corruption, a real security
21   - Serious issues as reported by a user of a distribution kernel may also
26     exists and additional information on the user-visible impact.
27   - No "This could be a problem..." type of things like a "theoretical race
30   - No "trivial" fixes without benefit for users (spelling changes, whitespace
34 Procedure for submitting patches to the -stable tree
35 ----------------------------------------------------
39    Security patches should not be handled (solely) by the -stable review
41    :ref:`Documentation/process/security-bugs.rst <securitybugs>`.
43 There are three options to submit a change to -stable trees:
45 1. Add a 'stable tag' to the description of a patch you then submit for
47 2. Ask the stable team to pick up a patch already mainlined.
48 3. Submit a patch to the stable team that is equivalent to a change already
56 options for cases where a mainlined patch needs adjustments to apply in older
63 e.g. a fix merged for 5.19-rc1 would be backported to 5.10.y, but not to 5.15.y.
70 To have a patch you submit for mainline inclusion later automatically picked up
71 for stable trees, add this tag in the sign-off area::
77 'git send-email', as mails sent to that address are not delivered anywhere.
79 Once the patch is mainlined it will be applied to the stable tree without
82 To send additional instructions to the stable team, use a shell-style inline
85 * Specify any additional patch prerequisites for cherry picking::
88     Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
91     Signed-off-by: Ingo Molnar <mingo@elte.hu>
95     git cherry-pick a1f84a3
96     git cherry-pick 1b9508f
97     git cherry-pick fd21073
98     git cherry-pick <this commit>
100   Note that for a patch series, you do not have to list as prerequisites the
102   patch series::
117     git cherry-pick <this commit>
119   For each "-stable" tree starting with the specified version.
126     Cc: <stable@vger.kernel.org> # after -rc3
130     Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
143 If the patch already has been merged to mainline, send an email to
144 stable@vger.kernel.org containing the subject of the patch, the commit ID,
153 Send the patch, after verifying that it follows the above rules, to
164 If the submitted patch deviates from the original upstream patch (for example
166 documented and justified in the patch description.
170 ------------------------
172 The sender will receive an ACK when the patch has been accepted into the
173 queue, or a NAK if the patch is rejected.  This response might take a few
176 If accepted, the patch will be added to the -stable queue, for review by other
181 ------------
183 - When the -stable maintainers decide for a review cycle, the patches will be
185   the patch (unless the submitter is the maintainer of the area) and CC: to
186   the linux-kernel mailing list.
187 - The review committee has 48 hours in which to ACK or NAK the patch.
188 - If the patch is rejected by a member of the committee, or linux-kernel
189   members object to the patch, bringing up issues that the maintainers and
190   members did not realize, the patch will be dropped from the queue.
191 - The ACKed patches will be posted again as part of release candidate (-rc)
193 - Usually only one -rc release is made, however if there are any outstanding
195   be queued. Additional -rc releases are then released and tested until no
197 - Responding to the -rc releases can be done on the mailing list by sending
198   a "Tested-by:" email with any testing information desired. The "Tested-by:"
200 - At the end of the review cycle, the new -stable release will be released
202 - Security patches will be accepted into the -stable tree directly from the
208 -----
210 - The queues of patches, for both completed versions and in progress
213     https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
215 - The finalized and tagged releases of all stable kernels can be found
220 - The release candidate of all stable kernel versions can be found at:
222     https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
225      The -stable-rc tree is a snapshot in time of the stable-queue tree and
231 ----------------
233 - This is made up of a number of kernel developers who have volunteered for