Documentation/livepatch/livepatch.rst

28 There are many situations where users are reluctant to reboot a system. It may
39 There are multiple mechanisms in the Linux kernel that are directly related
43   - The kernel probes are the most generic. The code can be redirected by
52     are in any way modified.
56 Most of these problems are solved by using the dynamic ftrace framework as
59 a live patch is called with the help of a custom ftrace handler. But there are
66 Functions are there for a reason. They take some input parameters, get or
73 Most of these changes are self contained and the function presents itself
77 But there are more complex fixes. For example, a patch might change
83 when it is safe to do so, e.g. when the affected locks are released
84 or no data are stored in the modified structures at the moment.
93 switching combined with kpatch's stack trace switching.  There are also
96 Patches are applied on a per-task basis, when the task is deemed safe to
98 transition state where tasks are converging to the patched state.
111    tasks.  If no affected functions are on the stack of a given task,
121    a) Patching I/O-bound user tasks which are sleeping on an affected
142 without HAVE_RELIABLE_STACKTRACE are not considered fully supported by
148 are stuck in the initial patch state.
156 determine which tasks are blocking completion of a patching operation.
159 transition, it shows -1.  Any tasks which are blocking the transition
163 actually delivered (there is no data in signal pending structures). Tasks are
175 patch, which functions are (un)patched, and which functions the blocking tasks
176 are sleeping in (/proc/<pid>/stack may help here). Removal (rmmod) of patch
189 For adding consistency model support to new architectures, there are a
197    klp_update_patch_state() in a safe location.  Kthreads are typically
200    point in the loop where there are no locks taken and all data
201    structures are in a well-defined state.
227 Livepatches are distributed using kernel modules, see
242 New versions of functions are typically just copied from the original
245 they can be declared as static because they are not called directly
248 The patch contains only functions that are really modified. But they
285     only when they are available.
293     symbols are found. The only exception are symbols from objects
306 Where the replacing and the disabling operations are mutually
316 in the module_init() callback. There are two main reasons:
331 First, the addresses of the patched functions are found according to their
333 are applied. The relevant entries are created under
337 Second, livepatch enters into a transition state where tasks are converging
368 patches are removed from the corresponding struct klp_ops. Also
382 First, livepatch enters into a transition state where tasks are converging
391 patch are removed from the corresponding struct klp_ops. The ftrace handler
401 Module removal is only safe when there are no users of functions provided
440     parameters are modified in any way. For example, livepatch requires
458   - Kprobes in the original function are ignored when the code is