Lines Matching +full:implementation +full:- +full:defined

15     5. Livepatch life-cycle
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
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.
87 The aim is to define a so-called consistency model. It attempts to define
88 conditions when the new implementation could be used so that the system
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
121    a) Patching I/O-bound user tasks which are sleeping on an affected
124    b) Patching CPU-bound user tasks.  If the task is highly CPU-bound
159 transition, it shows -1.  Any tasks which are blocking the transition
187 ---------------------------------------------------------
193    for non-DWARF unwinders, also making sure there's a way for the stack
201    structures are in a well-defined state.
207    There the safe location must be carefully selected on a case-by-case
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
232 relation between the original and the new implementation. Then there
240 ------------------
252 Documentation/livepatch/module-elf-format.rst for more details.
256 -------------
261   - struct klp_func is defined for each patched function. It describes
262     the relation between the original and the new implementation of a
268     Then it includes the address of the new function. It is defined
270     function is typically defined in the same source file.
278   - struct klp_object defines an array of patched functions (struct
288   - struct klp_patch defines an array of patched objects (struct
296     For more details on how the patch is applied on a per-task basis,
300 5. Livepatch life-cycle
312 ------------
325 -------------
329 implementation of the patched functions at this stage.
352     The right implementation is selected by the ftrace handler, see
361 --------------
373 See Documentation/livepatch/cumulative-patches.rst for more details.
377 --------------
390 to '0'. All the functions (struct klp_func) associated with the to-be-disabled
399 -------------
418 See Documentation/ABI/testing/sysfs-kernel-livepatch for more details.
424 The current Livepatch implementation has several limitations:
426   - Only functions that can be traced could be patched.
436   - Livepatch works reliably only when the dynamic ftrace is located at
441     using -fentry gcc compiler option on x86_64.
450   - Kretprobes using the ftrace framework conflict with the patched
458   - Kprobes in the original function are ignored when the code is
459     redirected to the new implementation.