Documentation/process/applying-patches.rst

3 Applying Patches To The Linux Kernel
11    This document is obsolete.  In most cases, rather than using ``patch``
14 A frequently asked question on the Linux Kernel Mailing List is how to apply
15 a patch to the kernel or, more specifically, what base kernel a patch for
19 In addition to explaining how to apply and revert patches, a brief
20 description of the different kernel trees (and examples of how to apply
33 should both be present in the patch file metadata or be possible to deduce
41 (or patch) file and makes the changes to the source tree described in it.
43 Patches for the Linux kernel are generated relative to the parent directory
44 holding the kernel source dir.
47 kernel source directories it was generated against (or some other directory
50 Since this is unlikely to match the name of the kernel source dir on your
52 unlabeled patch was generated against) you should change into your kernel
54 in the patch file when applying it (the ``-p1`` argument to ``patch`` does
57 To revert a previously applied patch, use the -R argument to patch.
60 	patch -p1 < ../patch-x.y.z
64 	patch -R -p1 < ../patch-x.y.z
71 done in several different ways.
73 In all the examples below I feed the file (in uncompressed form) to patch
76 	patch -p1 < path/to/patch-x.y.z
82 Patch can also get the name of the file to use via the -i argument, like
85 	patch -p1 -i path/to/patch-x.y.z
91 	xzcat path/to/patch-x.y.z.xz | patch -p1
92 	bzcat path/to/patch-x.y.z.gz | patch -p1
95 (what I assume you've done in the examples below), then you simply run
96 gunzip or xz on the file -- like this::
98 	gunzip patch-x.y.z.gz
99 	xz -d patch-x.y.z.xz
101 Which will leave you with a plain text patch-x.y.z file that you can feed to
102 patch via stdin or the ``-i`` argument, as you prefer.
104 A few other nice arguments for patch are ``-s`` which causes patch to be silent
106 screen too fast, and ``--dry-run`` which causes patch to just print a listing of
107 what would happen, but doesn't actually make any changes. Finally ``--verbose``
115 file in different ways.
118 around the bits being modified matches the context provided in the patch are
128 a change in the middle of the file but for some reasons a few lines have
129 been added or removed near the beginning of the file. In that case
144 If you don't have any third-party patches applied to your kernel source, but
145 only patches from kernel.org and you apply the patches in the correct order,
149 patch file is corrupted in some way. In that case you should probably try
150 re-downloading the patch and if things are still not OK then you'd be advised
151 to start with a fresh tree downloaded in full from kernel.org.
156 find a file to be patched. Most likely you forgot to specify -p1 or you are
157 in the wrong directory. Less often, you'll find patches that need to be
158 applied with ``-p0`` instead of ``-p1`` (reading the patch file should reveal if
159 this is the case -- if so, then this is an error by the person who created
164 of the change (in this example it needed to move 7 lines from where it
171 different kernel version than the one you are trying to patch.
179 If you get ``Reversed (or previously applied) patch detected!  Assume -R? [n]``
180 then patch detected that the change contained in the patch seems to have
183 If you actually did apply this patch previously and you just re-applied it
184 in error, then just say [n]o and abort this patch. If you applied this patch
185 previously and actually intended to revert it, but forgot to specify -R,
189 destination directories when creating the patch, and in that case reverting
190 the patch will in fact apply it.
192 A message similar to ``patch: **** unexpected end of file in patch`` or
193 ``patch unexpectedly ends in middle of line`` means that patch could make no
202 a patch from kernel.org to the correct version of an unmodified source tree.
203 So if you get these errors with kernel.org patches then you should probably
205 to start over with a fresh download of a full kernel tree and the patch you
219 This will let you move from something like 5.7.2 to 5.7.3 in a single
220 step. The -z flag to interdiff will even let you feed it patches in gzip or
224 Here's how you'd go from 5.7.2 to 5.7.3 in a single step::
226 	interdiff -z ../patch-5.7.2.gz ../patch-5.7.3.gz | patch -p1
229 do the additional steps since interdiff can get things wrong in some cases.
235 patch; lsdiff, which displays a short listing of affected files in a patch
244 The patches are available at https://kernel.org/
248 The 5.x.y (-stable) and 5.x patches live at
250 	https://www.kernel.org/pub/linux/kernel/v5.x/
252 The -rc patches are not stored on the webserver but are generated on
255 	https://git.kernel.org/torvalds/p/v5.1-rc1/v5.0
257 The stable -rc patches live at
259 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/
268 If regressions or other serious flaws are found, then a -stable fix patch
270 kernel is released, a patch is made available that is a delta between the
271 previous 5.x kernel and the new one.
275 base 5.x kernel -- if you need to move from 5.x.y to 5.x+1 you need to
282 	$ cd ~/linux-5.6		# change to kernel source dir
283 	$ patch -p1 < ../patch-5.7	# apply the 5.7 patch
285 	$ mv linux-5.6 linux-5.7	# rename source dir
289 	$ cd ~/linux-5.6.1		# change to kernel source dir
290 	$ patch -p1 -R < ../patch-5.6.1	# revert the 5.6.1 patch
292 	$ patch -p1 < ../patch-5.7	# apply new 5.7 patch
294 	$ mv linux-5.6.1 linux-5.7	# rename source dir
300 Kernels with 3-digit versions are -stable kernels. They contain small(ish)
302 in a given 5.x kernel.
305 kernel and are not interested in helping test development/experimental
308 If no 5.x.y kernel is available, then the highest numbered 5.x kernel is
309 the current stable kernel.
313  The -stable team usually do make incremental patches available as well
315  non-incremental ones below. The incremental ones can be found at
316  https://www.kernel.org/pub/linux/kernel/v5.x/incr/
319 patch does not apply on top of the 5.7.2 kernel source, but rather on top
320 of the base 5.7 kernel source.
322 So, in order to apply the 5.7.3 patch to your existing 5.7.2 kernel
324 base 5.7 kernel source) and then apply the new 5.7.3 patch.
328 	$ cd ~/linux-5.7.2		# change to the kernel source dir
329 	$ patch -p1 -R < ../patch-5.7.2	# revert the 5.7.2 patch
330 	$ patch -p1 < ../patch-5.7.3	# apply the new 5.7.3 patch
332 	$ mv linux-5.7.2 linux-5.7.3	# rename the kernel source dir
334 The -rc kernels
337 These are release-candidate kernels. These are development kernels released
338 by Linus whenever he deems the current git (the kernel's source management
339 tool) tree to be in a reasonably sane state adequate for testing.
344 stable kernel, so it is important that it be tested by as many people as
349 stuff (such people should see the sections about -next and -mm kernels below).
351 The -rc patches are not incremental, they apply to a base 5.x kernel, just
352 like the 5.x.y patches described above. The kernel version before the -rcN
353 suffix denotes the version of the kernel that this -rc kernel will eventually
356 So, 5.8-rc5 means that this is the fifth release candidate for the 5.8
357 kernel and the patch should be applied on top of the 5.7 kernel source.
361 	# first an example of moving from 5.7 to 5.8-rc3
363 	$ cd ~/linux-5.7			# change to the 5.7 source dir
364 	$ patch -p1 < ../patch-5.8-rc3		# apply the 5.8-rc3 patch
366 	$ mv linux-5.7 linux-5.8-rc3		# rename the source dir
368 	# now let's move from 5.8-rc3 to 5.8-rc5
370 	$ cd ~/linux-5.8-rc3			# change to the 5.8-rc3 dir
371 	$ patch -p1 -R < ../patch-5.8-rc3	# revert the 5.8-rc3 patch
372 	$ patch -p1 < ../patch-5.8-rc5		# apply the new 5.8-rc5 patch
374 	$ mv linux-5.8-rc3 linux-5.8-rc5	# rename the source dir
376 	# finally let's try and move from 5.7.3 to 5.8-rc5
378 	$ cd ~/linux-5.7.3			# change to the kernel source dir
379 	$ patch -p1 -R < ../patch-5.7.3		# revert the 5.7.3 patch
380 	$ patch -p1 < ../patch-5.8-rc5		# apply new 5.8-rc5 patch
382 	$ mv linux-5.7.3 linux-5.8-rc5		# rename the kernel source dir
385 The -mm patches and the linux-next tree
388 The -mm patches are experimental patches released by Andrew Morton.
390 In the past, -mm tree were used to also test subsystem patches, but this
392 `linux-next <https://www.kernel.org/doc/man-pages/linux-next.html>`
393 tree. The Subsystem maintainers push their patches first to linux-next,
396 The -mm patches serve as a sort of proving ground for new features and other
398 Once such patches has proved its worth in -mm for a while Andrew pushes
399 it on to Linus for inclusion in mainline.
401 The linux-next tree is daily updated, and includes the -mm patches.
402 Both are in constant flux and contains many experimental features, a
404 experimental of the branches described in this document.
408 sure you have up-to-date backups -- that goes for any experimental kernel but
409 even more so for -mm patches or using a Kernel from the linux-next tree).
411 Testing of -mm patches and linux-next is greatly appreciated since the whole
413 build breakage (and any other bug in general) before changes are merged into
416 But testers of -mm and linux-next should be aware that breakages are
417 more common than in any other tree.
420 This concludes this list of explanations of the various kernel trees.
422 the kernel.