Lines Matching +full:in +full:- +full:functions
13 4.1. New functions
15 5. Livepatch life-cycle
30 heavy load during peak usage. In addition to keeping systems up and running,
33 functions without a system reboot.
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
46 - The function tracer calls the code from a predefined location that is
48 compiler using the '-pg' gcc option.
50 - Livepatching typically needs to redirect the code at the very beginning
52 are in any way modified.
66 Functions are there for a reason. They take some input parameters, get or
67 release locks, read, process, and even write some data in a defined way,
68 have return values. In other words, each function has a defined semantic.
70 Many fixes do not change the semantic of the modified functions. For
74 the same way to the rest of the system. In this case, the functions might
78 ordering of locking in multiple functions at the same time. Or a patch
80 all the relevant functions. In this case, the affected unit
82 the functions at the same time. Also the switch must happen only
84 or no data are stored in the modified structures at the moment.
86 The theory about how to apply functions a safe way is rather complex.
87 The aim is to define a so-called consistency model. It attempts to define
92 kpatch: it uses kGraft's per-task consistency and syscall barrier
96 Patches are applied on a per-task basis, when the task is deemed safe to
99 Usually this transition state can complete in a few seconds. The same
111 tasks. If no affected functions are on the stack of a given task,
112 the task is patched. In most cases this will patch most or all of
119 user space IRQ, or a signal. It's useful in the following cases:
121 a) Patching I/O-bound user tasks which are sleeping on an affected
122 function. In this case you have to send SIGSTOP and SIGCONT to
124 b) Patching CPU-bound user tasks. If the task is highly CPU-bound
129 instead have a klp_update_patch_state() call in the idle loop which
137 returns. In this case you would have to signal the tasks. This
146 is in transition. Only a single patch can be in transition at a given
147 time. A patch can remain in transition indefinitely, if any of the tasks
148 are stuck in the initial patch state.
152 the transition is in progress. Then all the tasks will attempt to
157 If a patch is in transition, this file shows 0 to indicate the task is
158 unpatched and 1 to indicate it's patched. Otherwise, if no patch is in
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
178 guaranteed there is no task sleeping in such module. It implies unbounded
179 reference count if a patch module is disabled and enabled in a loop.
187 ---------------------------------------------------------
193 for non-DWARF unwinders, also making sure there's a way for the stack
197 klp_update_patch_state() in a safe location. Kthreads are typically
198 in an infinite loop which does some action repeatedly. The safe
200 point in the loop where there are no locks taken and all data
201 structures are in a well-defined state.
204 API. These kthreads process independent actions in a generic loop.
207 There the safe location must be carefully selected on a case-by-case
210 In that case, arches without HAVE_RELIABLE_STACKTRACE would still be
211 able to use the non-stack-checking parts of the consistency model:
228 samples/livepatch/livepatch-sample.c.
230 The module includes a new implementation of functions that we want
231 to replace. In addition, it defines some structures describing the
235 livepatch module is removed. All this is explained in more details in
239 4.1. New functions
240 ------------------
242 New versions of functions are typically just copied from the original
244 can be distinguished from the original ones, e.g. in a backtrace. Also
248 The patch contains only functions that are really modified. But they
249 might want to access functions or data from the original source file
251 relocation section in the generated livepatch module, see
252 Documentation/livepatch/module-elf-format.rst for more details.
256 -------------
261 - struct klp_func is defined for each patched function. It describes
270 function is typically defined in the same source file.
272 As an optional parameter, the symbol position in the kallsyms database can
273 be used to disambiguate functions of the same name. This is not the
274 absolute position in the database, but rather the order it has been found
278 - struct klp_object defines an array of patched functions (struct
279 klp_func) in the same object. Where the object is either vmlinux
282 The structure helps to group and handle functions for each object
284 the patch itself and the relevant functions might be patched
288 - struct klp_patch defines an array of patched objects (struct
291 This structure handles all patched functions consistently and eventually,
296 For more details on how the patch is applied on a per-task basis,
300 5. Livepatch life-cycle
312 ------------
316 in the module_init() callback. There are two main reasons:
325 -------------
329 implementation of the patched functions at this stage.
331 First, the addresses of the patched functions are found according to their
332 names. The special relocations, mentioned in the section "New functions",
341 in /sys/kernel/livepatch/<name>/transition. For more information about
349 Note that functions might be patched multiple times. The ftrace handler
356 because they help keeping the consistency of all changes. In this case,
357 functions might be patched two times only during the transition period.
361 --------------
367 all the functions (struct klp_func) associated with the replaced
373 See Documentation/livepatch/cumulative-patches.rst for more details.
377 --------------
385 indicated by a value of '1' in /sys/kernel/livepatch/<name>/transition.
390 to '0'. All the functions (struct klp_func) associated with the to-be-disabled
399 -------------
401 Module removal is only safe when there are no users of functions provided
405 guaranteed that no task sleeps or runs in the old code.
418 See Documentation/ABI/testing/sysfs-kernel-livepatch for more details.
426 - Only functions that can be traced could be patched.
428 Livepatch is based on the dynamic ftrace. In particular, functions
430 patched. Otherwise, the code would end up in an infinite loop. A
431 potential mistake is prevented by marking the problematic functions
436 - Livepatch works reliably only when the dynamic ftrace is located at
440 parameters are modified in any way. For example, livepatch requires
441 using -fentry gcc compiler option on x86_64.
450 - Kretprobes using the ftrace framework conflict with the patched
451 functions.
455 is rejected when the handler is already in use by the other.
458 - Kprobes in the original function are ignored when the code is
461 There is a work in progress to add warnings about this situation.