1 .. _stable_kernel_rules:
2
3 Everything you ever wanted to know about Linux
4 ==============================================
5
6 Rules on what kind of patches are accepted, an
7 "-stable" tree:
8
9 - It or an equivalent fix must already exist i
10 - It must be obviously correct and tested.
11 - It cannot be bigger than 100 lines, with con
12 - It must follow the
13 :ref:`Documentation/process/submitting-patch
14 rules.
15 - It must either fix a real bug that bothers p
16 To elaborate on the former:
17
18 - It fixes a problem like an oops, a hang, d
19 issue, a hardware quirk, a build error (bu
20 CONFIG_BROKEN), or some "oh, that's not go
21 - Serious issues as reported by a user of a
22 be considered if they fix a notable perfor
23 As these fixes are not as obvious and have
24 regression they should only be submitted b
25 maintainer and include an addendum linking
26 exists and additional information on the u
27 - No "This could be a problem..." type of th
28 condition", unless an explanation of how t
29 provided.
30 - No "trivial" fixes without benefit for use
31 cleanups, etc).
32
33
34 Procedure for submitting patches to the -stabl
35 ----------------------------------------------
36
37 .. note::
38
39 Security patches should not be handled (sol
40 process but should follow the procedures in
41 :ref:`Documentation/process/security-bugs.r
42
43 There are three options to submit a change to
44
45 1. Add a 'stable tag' to the description of a
46 mainline inclusion.
47 2. Ask the stable team to pick up a patch alre
48 3. Submit a patch to the stable team that is e
49 mainlined.
50
51 The sections below describe each of the option
52
53 :ref:`option_1` is **strongly** preferred, it
54 :ref:`option_2` is mainly meant for changes wh
55 at the time of submission. :ref:`option_3` is
56 options for cases where a mainlined patch need
57 series (for example due to API changes).
58
59 When using option 2 or 3 you can ask for your
60 stable series. When doing so, ensure the fix o
61 submitted, or already present in all newer sta
62 meant to prevent regressions that users might
63 e.g. a fix merged for 5.19-rc1 would be backpo
64
65 .. _option_1:
66
67 Option 1
68 ********
69
70 To have a patch you submit for mainline inclus
71 for stable trees, add this tag in the sign-off
72
73 Cc: stable@vger.kernel.org
74
75 Use ``Cc: stable@kernel.org`` instead when fix
76 it reduces the chance of accidentally exposing
77 'git send-email', as mails sent to that addres
78
79 Once the patch is mainlined it will be applied
80 anything else needing to be done by the author
81
82 To send additional instructions to the stable
83 comment to pass arbitrary or predefined notes:
84
85 * Specify any additional patch prerequisites f
86
87 Cc: <stable@vger.kernel.org> # 3.3.x: a1f84
88 Cc: <stable@vger.kernel.org> # 3.3.x: 1b950
89 Cc: <stable@vger.kernel.org> # 3.3.x: fd210
90 Cc: <stable@vger.kernel.org> # 3.3.x
91 Signed-off-by: Ingo Molnar <mingo@elte.hu>
92
93 The tag sequence has the meaning of::
94
95 git cherry-pick a1f84a3
96 git cherry-pick 1b9508f
97 git cherry-pick fd21073
98 git cherry-pick <this commit>
99
100 Note that for a patch series, you do not hav
101 patches present in the series itself. For ex
102 patch series::
103
104 patch1
105 patch2
106
107 where patch2 depends on patch1, you do not h
108 prerequisite of patch2 if you have already m
109 inclusion.
110
111 * Point out kernel version prerequisites::
112
113 Cc: <stable@vger.kernel.org> # 3.3.x
114
115 The tag has the meaning of::
116
117 git cherry-pick <this commit>
118
119 For each "-stable" tree starting with the sp
120
121 Note, such tagging is unnecessary if the sta
122 appropriate versions from Fixes: tags.
123
124 * Delay pick up of patches::
125
126 Cc: <stable@vger.kernel.org> # after -rc3
127
128 * Point out known problems::
129
130 Cc: <stable@vger.kernel.org> # see patch de
131
132 There furthermore is a variant of the stable t
133 team's backporting tools (e.g AUTOSEL or scrip
134 containing a 'Fixes:' tag) ignore a change::
135
136 Cc: <stable+noautosel@kernel.org> # reason
137
138 .. _option_2:
139
140 Option 2
141 ********
142
143 If the patch already has been merged to mainli
144 stable@vger.kernel.org containing the subject
145 why you think it should be applied, and what k
146 be applied to.
147
148 .. _option_3:
149
150 Option 3
151 ********
152
153 Send the patch, after verifying that it follow
154 stable@vger.kernel.org and mention the kernel
155 to. When doing so, you must note the upstream
156 submission with a separate line above the comm
157
158 commit <sha1> upstream.
159
160 Or alternatively::
161
162 [ Upstream commit <sha1> ]
163
164 If the submitted patch deviates from the origi
165 because it had to be adjusted for the older AP
166 documented and justified in the patch descript
167
168
169 Following the submission
170 ------------------------
171
172 The sender will receive an ACK when the patch
173 queue, or a NAK if the patch is rejected. Thi
174 days, according to the schedules of the stable
175
176 If accepted, the patch will be added to the -s
177 developers and by the relevant subsystem maint
178
179
180 Review cycle
181 ------------
182
183 - When the -stable maintainers decide for a re
184 sent to the review committee, and the mainta
185 the patch (unless the submitter is the maint
186 the linux-kernel mailing list.
187 - The review committee has 48 hours in which t
188 - If the patch is rejected by a member of the
189 members object to the patch, bringing up iss
190 members did not realize, the patch will be d
191 - The ACKed patches will be posted again as pa
192 to be tested by developers and testers.
193 - Usually only one -rc release is made, howeve
194 issues, some patches may be modified or drop
195 be queued. Additional -rc releases are then
196 issues are found.
197 - Responding to the -rc releases can be done o
198 a "Tested-by:" email with any testing inform
199 tags will be collected and added to the rele
200 - At the end of the review cycle, the new -sta
201 containing all the queued and tested patches
202 - Security patches will be accepted into the -
203 security kernel team, and not go through the
204 Contact the kernel security team for more de
205
206
207 Trees
208 -----
209
210 - The queues of patches, for both completed ve
211 versions can be found at:
212
213 https://git.kernel.org/pub/scm/linux/kerne
214
215 - The finalized and tagged releases of all sta
216 in separate branches per version at:
217
218 https://git.kernel.org/pub/scm/linux/kerne
219
220 - The release candidate of all stable kernel v
221
222 https://git.kernel.org/pub/scm/linux/kerne
223
224 .. warning::
225 The -stable-rc tree is a snapshot in time
226 will change frequently, hence will be reb
227 used for testing purposes (e.g. to be con
228
229
230 Review committee
231 ----------------
232
233 - This is made up of a number of kernel develo
234 this task, and a few that haven't.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.