Documentation/process/applying-patches.rst

11    This document is obsolete.  In most cases, rather than using ``patch``
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
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
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``
121 If patch encounters something that doesn't look quite right it has two
125 One example of something that's not 'quite right' that patch will attempt to
136 right it doesn't /always/ get it right, and the result will sometimes be
144 If you don't have any third-party patches applied to your kernel source, but
150 re-downloading the patch and if things are still not OK then you'd be advised
156 find a file to be patched. Most likely you forgot to specify -p1 or you are
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
179 If you get ``Reversed (or previously applied) patch detected!  Assume -R? [n]``
183 If you actually did apply this patch previously and you just re-applied it
185 previously and actually intended to revert it, but forgot to specify -R,
220 step. The -z flag to interdiff will even let you feed it patches in gzip or
226 	interdiff -z ../patch-5.7.2.gz ../patch-5.7.3.gz | patch -p1
245 Most recent patches are linked from the front page, but they also have
248 The 5.x.y (-stable) and 5.x patches live at
256 The -rc patches are not stored on the webserver but are generated on
259 	https://git.kernel.org/torvalds/p/v5.1-rc1/v5.0
261 The stable -rc patches live at
263 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/
270 release is the most recent.
272 If regressions or other serious flaws are found, then a -stable fix patch
279 base 5.x kernel -- if you need to move from 5.x.y to 5.x+1 you need to
286 	$ cd ~/linux-5.6		# change to kernel source dir
287 	$ patch -p1 < ../patch-5.7	# apply the 5.7 patch
289 	$ mv linux-5.6 linux-5.7	# rename source dir
293 	$ cd ~/linux-5.6.1		# change to kernel source dir
294 	$ patch -p1 -R < ../patch-5.6.1	# revert the 5.6.1 patch
296 	$ patch -p1 < ../patch-5.7	# apply new 5.7 patch
298 	$ mv linux-5.6.1 linux-5.7	# rename source dir
304 Kernels with 3-digit versions are -stable kernels. They contain small(ish)
308 This is the recommended branch for users who want the most recent stable
315 The -stable team provides normal as well as incremental patches. Below is
331 	$ cd ~/linux-5.7.2		# change to the kernel source dir
332 	$ patch -p1 -R < ../patch-5.7.2	# revert the 5.7.2 patch
333 	$ patch -p1 < ../patch-5.7.3	# apply the new 5.7.3 patch
335 	$ mv linux-5.7.2 linux-5.7.3	# rename the kernel source dir
342 (5.x.y-1).
346 	$ cd ~/linux-5.7.2		# change to the kernel source dir
347 	$ patch -p1 < ../patch-5.7.2-3	# apply the new 5.7.3 patch
349 	$ mv linux-5.7.2 linux-5.7.3	# rename the kernel source dir
352 The -rc kernels
355 These are release-candidate kernels. These are development kernels released
360 you intend to run them. This is however the most stable of the main
367 stuff (such people should see the sections about -next and -mm kernels below).
369 The -rc patches are not incremental, they apply to a base 5.x kernel, just
370 like the 5.x.y patches described above. The kernel version before the -rcN
371 suffix denotes the version of the kernel that this -rc kernel will eventually
374 So, 5.8-rc5 means that this is the fifth release candidate for the 5.8
379 	# first an example of moving from 5.7 to 5.8-rc3
381 	$ cd ~/linux-5.7			# change to the 5.7 source dir
382 	$ patch -p1 < ../patch-5.8-rc3		# apply the 5.8-rc3 patch
384 	$ mv linux-5.7 linux-5.8-rc3		# rename the source dir
386 	# now let's move from 5.8-rc3 to 5.8-rc5
388 	$ cd ~/linux-5.8-rc3			# change to the 5.8-rc3 dir
389 	$ patch -p1 -R < ../patch-5.8-rc3	# revert the 5.8-rc3 patch
390 	$ patch -p1 < ../patch-5.8-rc5		# apply the new 5.8-rc5 patch
392 	$ mv linux-5.8-rc3 linux-5.8-rc5	# rename the source dir
394 	# finally let's try and move from 5.7.3 to 5.8-rc5
396 	$ cd ~/linux-5.7.3			# change to the kernel source dir
397 	$ patch -p1 -R < ../patch-5.7.3		# revert the 5.7.3 patch
398 	$ patch -p1 < ../patch-5.8-rc5		# apply new 5.8-rc5 patch
400 	$ mv linux-5.7.3 linux-5.8-rc5		# rename the kernel source dir
403 The -mm patches and the linux-next tree
406 The -mm patches are experimental patches released by Andrew Morton.
408 In the past, -mm tree were used to also test subsystem patches, but this
410 `linux-next` (https://www.kernel.org/doc/man-pages/linux-next.html)
411 tree. The Subsystem maintainers push their patches first to linux-next,
414 The -mm patches serve as a sort of proving ground for new features and other
416 Once such patches has proved its worth in -mm for a while Andrew pushes
419 The linux-next tree is daily updated, and includes the -mm patches.
421 lot of debugging patches not appropriate for mainline etc., and is the most
426 sure you have up-to-date backups -- that goes for any experimental kernel but
427 even more so for -mm patches or using a Kernel from the linux-next tree).
429 Testing of -mm patches and linux-next is greatly appreciated since the whole
434 But testers of -mm and linux-next should be aware that breakages are