Documentation/livepatch/livepatch.rst

15 There are many situations where users are reluctant to reboot a system. It may
26 There are multiple mechanisms in the Linux kernel that are directly related
30   - The kernel probes are the most generic. The code can be redirected by
39     are in any way modified.
43 Most of these problems are solved by using the dynamic ftrace framework as
46 a live patch is called with the help of a custom ftrace handler. But there are
53 Functions are there for a reason. They take some input parameters, get or
60 Most of these changes are self contained and the function presents itself
64 But there are more complex fixes. For example, a patch might change
70 when it is safe to do so, e.g. when the affected locks are released
71 or no data are stored in the modified structures at the moment.
80 switching combined with kpatch's stack trace switching.  There are also
83 Patches are applied on a per-task basis, when the task is deemed safe to
85 transition state where tasks are converging to the patched state.
98    tasks.  If no affected functions are on the stack of a given task,
108    a) Patching I/O-bound user tasks which are sleeping on an affected
129 without HAVE_RELIABLE_STACKTRACE are not considered fully supported by
135 are stuck in the initial patch state.
143 determine which tasks are blocking completion of a patching operation.
146 transition, it shows -1.  Any tasks which are blocking the transition
150 actually delivered (there is no data in signal pending structures). Tasks are
162 patch, which functions are (un)patched, and which functions the blocking tasks
163 are sleeping in (/proc/<pid>/stack may help here). Removal (rmmod) of patch
176 For adding consistency model support to new architectures, there are a
184    klp_update_patch_state() in a safe location.  Kthreads are typically
187    point in the loop where there are no locks taken and all data
188    structures are in a well-defined state.
214 Livepatches are distributed using kernel modules, see
229 New versions of functions are typically just copied from the original
232 they can be declared as static because they are not called directly
235 The patch contains only functions that are really modified. But they
272     only when they are available.
280     symbols are found. The only exception are symbols from objects
293 Where the replacing and the disabling operations are mutually
303 in the module_init() callback. There are two main reasons:
318 First, the addresses of the patched functions are found according to their
320 are applied. The relevant entries are created under
324 Second, livepatch enters into a transition state where tasks are converging
355 patches are removed from the corresponding struct klp_ops. Also
369 First, livepatch enters into a transition state where tasks are converging
378 patch are removed from the corresponding struct klp_ops. The ftrace handler
388 Module removal is only safe when there are no users of functions provided
427     parameters are modified in any way. For example, livepatch requires
445   - Kprobes in the original function are ignored when the code is