1 .. _applying_patches:
2
3 Applying Patches To The Linux Kernel
4 ++++++++++++++++++++++++++++++++++++
5
6 Original by:
7 Jesper Juhl, August 2005
8
9 .. note::
10
11 This document is obsolete. In most cases,
12 manually, you'll almost certainly want to l
13
14 A frequently asked question on the Linux Kerne
15 a patch to the kernel or, more specifically, w
16 one of the many trees/branches should be appli
17 will explain this to you.
18
19 In addition to explaining how to apply and rev
20 description of the different kernel trees (and
21 their specific patches) is also provided.
22
23
24 What is a patch?
25 ================
26
27 A patch is a small text document containing a
28 different versions of a source tree. Patches a
29 program.
30
31 To correctly apply a patch you need to know wh
32 and what new version the patch will change the
33 should both be present in the patch file metad
34 from the filename.
35
36
37 How do I apply or revert a patch?
38 =================================
39
40 You apply a patch with the ``patch`` program.
41 (or patch) file and makes the changes to the s
42
43 Patches for the Linux kernel are generated rel
44 holding the kernel source dir.
45
46 This means that paths to files inside the patc
47 kernel source directories it was generated aga
48 names like "a/" and "b/").
49
50 Since this is unlikely to match the name of th
51 local machine (but is often useful info to see
52 unlabeled patch was generated against) you sho
53 source directory and then strip the first elem
54 in the patch file when applying it (the ``-p1`
55 this).
56
57 To revert a previously applied patch, use the
58 So, if you applied a patch like this::
59
60 patch -p1 < ../patch-x.y.z
61
62 You can revert (undo) it like this::
63
64 patch -R -p1 < ../patch-x.y.z
65
66
67 How do I feed a patch/diff file to ``patch``?
68 =============================================
69
70 This (as usual with Linux and other UNIX like
71 done in several different ways.
72
73 In all the examples below I feed the file (in
74 via stdin using the following syntax::
75
76 patch -p1 < path/to/patch-x.y.z
77
78 If you just want to be able to follow the exam
79 know of more than one way to use patch, then y
80 section here.
81
82 Patch can also get the name of the file to use
83 this::
84
85 patch -p1 -i path/to/patch-x.y.z
86
87 If your patch file is compressed with gzip or
88 uncompress it before applying it, then you can
89 instead::
90
91 xzcat path/to/patch-x.y.z.xz | patch -
92 bzcat path/to/patch-x.y.z.gz | patch -
93
94 If you wish to uncompress the patch file by ha
95 (what I assume you've done in the examples bel
96 gunzip or xz on the file -- like this::
97
98 gunzip patch-x.y.z.gz
99 xz -d patch-x.y.z.xz
100
101 Which will leave you with a plain text patch-x
102 patch via stdin or the ``-i`` argument, as you
103
104 A few other nice arguments for patch are ``-s`
105 except for errors which is nice to prevent err
106 screen too fast, and ``--dry-run`` which cause
107 what would happen, but doesn't actually make a
108 tells patch to print more information about th
109
110
111 Common errors when patching
112 ===========================
113
114 When patch applies a patch file it attempts to
115 file in different ways.
116
117 Checking that the file looks like a valid patc
118 around the bits being modified matches the con
119 just two of the basic sanity checks patch does
120
121 If patch encounters something that doesn't loo
122 options. It can either refuse to apply the cha
123 to find a way to make the patch apply with a f
124
125 One example of something that's not 'quite rig
126 fix up is if all the context matches, the line
127 line numbers are different. This can happen, f
128 a change in the middle of the file but for som
129 been added or removed near the beginning of th
130 everything looks good it has just moved up or
131 usually adjust the line numbers and apply the
132
133 Whenever patch applies a patch that it had to
134 it'll tell you about it by saying the patch ap
135 You should be wary of such changes since even
136 right it doesn't /always/ get it right, and th
137 wrong.
138
139 When patch encounters a change that it can't f
140 outright and leaves a file with a ``.rej`` ext
141 read this file to see exactly what change coul
142 go fix it up by hand if you wish.
143
144 If you don't have any third-party patches appl
145 only patches from kernel.org and you apply the
146 and have made no modifications yourself to the
147 never see a fuzz or reject message from patch.
148 anyway, then there's a high risk that either y
149 patch file is corrupted in some way. In that c
150 re-downloading the patch and if things are sti
151 to start with a fresh tree downloaded in full
152
153 Let's look a bit more at some of the messages
154
155 If patch stops and presents a ``File to patch:
156 find a file to be patched. Most likely you for
157 in the wrong directory. Less often, you'll fin
158 applied with ``-p0`` instead of ``-p1`` (readi
159 this is the case -- if so, then this is an err
160 the patch but is not fatal).
161
162 If you get ``Hunk #2 succeeded at 1887 with fu
163 message similar to that, then it means that pa
164 of the change (in this example it needed to mo
165 expected to make the change to make it fit).
166
167 The resulting file may or may not be OK, depen
168 was different than expected.
169
170 This often happens if you try to apply a patch
171 different kernel version than the one you are
172
173 If you get a message like ``Hunk #3 FAILED at
174 patch could not be applied correctly and the p
175 fuzz its way through. This will generate a ``.
176 caused the patch to fail and also a ``.orig``
177 content that couldn't be changed.
178
179 If you get ``Reversed (or previously applied)
180 then patch detected that the change contained
181 already been made.
182
183 If you actually did apply this patch previousl
184 in error, then just say [n]o and abort this pa
185 previously and actually intended to revert it,
186 then you can say [**y**]es here to make patch
187
188 This can also happen if the creator of the pat
189 destination directories when creating the patc
190 the patch will in fact apply it.
191
192 A message similar to ``patch: **** unexpected
193 ``patch unexpectedly ends in middle of line``
194 sense of the file you fed to it. Either your d
195 feed patch a compressed patch file without unc
196 file that you are using has been mangled by a
197 agent along the way somewhere, e.g., by splitt
198 Often these warnings can easily be fixed by jo
199 two lines that had been split.
200
201 As I already mentioned above, these errors sho
202 a patch from kernel.org to the correct version
203 So if you get these errors with kernel.org pat
204 assume that either your patch file or your tre
205 to start over with a fresh download of a full
206 wish to apply.
207
208
209 Are there any alternatives to ``patch``?
210 ========================================
211
212
213 Yes there are alternatives.
214
215 You can use the ``interdiff`` program (http://
216 generate a patch representing the differences
217 apply the result.
218
219 This will let you move from something like 5.7
220 step. The -z flag to interdiff will even let y
221 bzip2 compressed form directly without the use
222 decompression.
223
224 Here's how you'd go from 5.7.2 to 5.7.3 in a s
225
226 interdiff -z ../patch-5.7.2.gz ../patc
227
228 Although interdiff may save you a step or two
229 do the additional steps since interdiff can ge
230
231 Another alternative is ``ketchup``, which is a
232 downloading and applying of patches (https://w
233
234 Other nice tools are diffstat, which shows a s
235 patch; lsdiff, which displays a short listing
236 file, along with (optionally) the line numbers
237 and grepdiff, which displays a list of the fil
238 the patch contains a given regular expression.
239
240
241 Where can I download the patches?
242 =================================
243
244 The patches are available at https://kernel.or
245 Most recent patches are linked from the front
246 specific homes.
247
248 The 5.x.y (-stable) and 5.x patches live at
249
250 https://www.kernel.org/pub/linux/kerne
251
252 The 5.x.y incremental patches live at
253
254 https://www.kernel.org/pub/linux/kerne
255
256 The -rc patches are not stored on the webserve
257 demand from git tags such as
258
259 https://git.kernel.org/torvalds/p/v5.1
260
261 The stable -rc patches live at
262
263 https://www.kernel.org/pub/linux/kerne
264
265
266 The 5.x kernels
267 ===============
268
269 These are the base stable releases released by
270 release is the most recent.
271
272 If regressions or other serious flaws are foun
273 will be released (see below) on top of this ba
274 kernel is released, a patch is made available
275 previous 5.x kernel and the new one.
276
277 To apply a patch moving from 5.6 to 5.7, you'd
278 that such patches do **NOT** apply on top of 5
279 base 5.x kernel -- if you need to move from 5.
280 first revert the 5.x.y patch).
281
282 Here are some examples::
283
284 # moving from 5.6 to 5.7
285
286 $ cd ~/linux-5.6 # chan
287 $ patch -p1 < ../patch-5.7 # appl
288 $ cd ..
289 $ mv linux-5.6 linux-5.7 # rena
290
291 # moving from 5.6.1 to 5.7
292
293 $ cd ~/linux-5.6.1 # chan
294 $ patch -p1 -R < ../patch-5.6.1 # reve
295 # sour
296 $ patch -p1 < ../patch-5.7 # appl
297 $ cd ..
298 $ mv linux-5.6.1 linux-5.7 # rena
299
300
301 The 5.x.y kernels
302 =================
303
304 Kernels with 3-digit versions are -stable kern
305 critical fixes for security problems or signif
306 in a given 5.x kernel.
307
308 This is the recommended branch for users who w
309 kernel and are not interested in helping test
310 versions.
311
312 If no 5.x.y kernel is available, then the high
313 the current stable kernel.
314
315 The -stable team provides normal as well as in
316 how to apply these patches.
317
318 Normal patches
319 ~~~~~~~~~~~~~~
320
321 These patches are not incremental, meaning tha
322 patch does not apply on top of the 5.7.2 kerne
323 of the base 5.7 kernel source.
324
325 So, in order to apply the 5.7.3 patch to your
326 source you have to first back out the 5.7.2 pa
327 base 5.7 kernel source) and then apply the new
328
329 Here's a small example::
330
331 $ cd ~/linux-5.7.2 # chan
332 $ patch -p1 -R < ../patch-5.7.2 # reve
333 $ patch -p1 < ../patch-5.7.3 # appl
334 $ cd ..
335 $ mv linux-5.7.2 linux-5.7.3 # rena
336
337 Incremental patches
338 ~~~~~~~~~~~~~~~~~~~
339
340 Incremental patches are different: instead of
341 of base 5.x kernel, they are applied on top of
342 (5.x.y-1).
343
344 Here's the example to apply these::
345
346 $ cd ~/linux-5.7.2 # chan
347 $ patch -p1 < ../patch-5.7.2-3 # appl
348 $ cd ..
349 $ mv linux-5.7.2 linux-5.7.3 # rena
350
351
352 The -rc kernels
353 ===============
354
355 These are release-candidate kernels. These are
356 by Linus whenever he deems the current git (th
357 tool) tree to be in a reasonably sane state ad
358
359 These kernels are not stable and you should ex
360 you intend to run them. This is however the mo
361 development branches and is also what will eve
362 stable kernel, so it is important that it be t
363 possible.
364
365 This is a good branch to run for people who wa
366 development kernels but do not want to run som
367 stuff (such people should see the sections abo
368
369 The -rc patches are not incremental, they appl
370 like the 5.x.y patches described above. The ke
371 suffix denotes the version of the kernel that
372 turn into.
373
374 So, 5.8-rc5 means that this is the fifth relea
375 kernel and the patch should be applied on top
376
377 Here are 3 examples of how to apply these patc
378
379 # first an example of moving from 5.7
380
381 $ cd ~/linux-5.7
382 $ patch -p1 < ../patch-5.8-rc3
383 $ cd ..
384 $ mv linux-5.7 linux-5.8-rc3
385
386 # now let's move from 5.8-rc3 to 5.8-r
387
388 $ cd ~/linux-5.8-rc3
389 $ patch -p1 -R < ../patch-5.8-rc3
390 $ patch -p1 < ../patch-5.8-rc5
391 $ cd ..
392 $ mv linux-5.8-rc3 linux-5.8-rc5
393
394 # finally let's try and move from 5.7.
395
396 $ cd ~/linux-5.7.3
397 $ patch -p1 -R < ../patch-5.7.3
398 $ patch -p1 < ../patch-5.8-rc5
399 $ cd ..
400 $ mv linux-5.7.3 linux-5.8-rc5
401
402
403 The -mm patches and the linux-next tree
404 =======================================
405
406 The -mm patches are experimental patches relea
407
408 In the past, -mm tree were used to also test s
409 function is now done via the
410 `linux-next` (https://www.kernel.org/doc/man-p
411 tree. The Subsystem maintainers push their pat
412 and, during the merge window, sends them direc
413
414 The -mm patches serve as a sort of proving gro
415 experimental patches that aren't merged via a
416 Once such patches has proved its worth in -mm
417 it on to Linus for inclusion in mainline.
418
419 The linux-next tree is daily updated, and incl
420 Both are in constant flux and contains many ex
421 lot of debugging patches not appropriate for m
422 experimental of the branches described in this
423
424 These patches are not appropriate for use on s
425 stable and they are more risky to run than any
426 sure you have up-to-date backups -- that goes
427 even more so for -mm patches or using a Kernel
428
429 Testing of -mm patches and linux-next is great
430 point of those are to weed out regressions, cr
431 build breakage (and any other bug in general)
432 the more stable mainline Linus tree.
433
434 But testers of -mm and linux-next should be aw
435 more common than in any other tree.
436
437
438 This concludes this list of explanations of th
439 I hope you are now clear on how to apply the v
440 the kernel.
441
442 Thank you's to Randy Dunlap, Rolf Eike Beer, L
443 Johannes Stezenbach, Grant Coady, Pavel Machek
444 forgotten for their reviews and contributions
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.