1 ===================================
2 Atomic Replace & Cumulative Patches
3 ===================================
4
5 There might be dependencies between livepatche
6 to do different changes to the same function(s
7 an order in which the patches will be installe
8 from any newer livepatch must be done on top o
9
10 This might become a maintenance nightmare. Esp
11 modified the same function in different ways.
12
13 An elegant solution comes with the feature cal
14 creation of so called "Cumulative Patches". Th
15 from all older livepatches and completely repl
16
17 Usage
18 -----
19
20 The atomic replace can be enabled by setting "
21 for example::
22
23 static struct klp_patch patch = {
24 .mod = THIS_MODULE,
25 .objs = objs,
26 .replace = true,
27 };
28
29 All processes are then migrated to use the cod
30 Once the transition is finished, all older pat
31 disabled.
32
33 Ftrace handlers are transparently removed from
34 longer modified by the new cumulative patch.
35
36 As a result, the livepatch authors might maint
37 cumulative patch. It helps to keep the patch c
38 removing various fixes or features.
39
40 Users could keep only the last patch installed
41 the transition to has finished. It helps to cl
42 actually in use. Also the livepatch might then
43 module that modifies the kernel behavior. The
44 it can be updated at runtime without breaking
45
46
47 Features
48 --------
49
50 The atomic replace allows:
51
52 - Atomically revert some functions in a prev
53 upgrading other functions.
54
55 - Remove eventual performance impact caused
56 for functions that are no longer patched.
57
58 - Decrease user confusion about dependencies
59
60
61 Limitations:
62 ------------
63
64 - Once the operation finishes, there is no s
65 to reverse it and restore the replaced pat
66
67 A good practice is to set .replace flag in
68 Then re-adding an older livepatch is equiv
69 to that patch. This is safe as long as the
70 extra modifications in (un)patching callba
71 or module_exit() functions, see below.
72
73 Also note that the replaced patch can be r
74 only when the transition was not forced.
75
76
77 - Only the (un)patching callbacks from the _
78 executed. Any callbacks from the replaced
79
80 In other words, the cumulative patch is re
81 that are necessary to properly replace any
82
83 As a result, it might be dangerous to repl
84 older ones. The old livepatches might not
85
86 This might be seen as a limitation in some
87 easier in many others. Only the new cumula
88 fixes/features are added/removed and what
89 for a smooth transition.
90
91 In any case, it would be a nightmare to th
92 the various callbacks and their interactio
93 enabled patches were called.
94
95
96 - There is no special handling of shadow var
97 must create their own rules how to pass th
98 patch to the other. Especially that they s
99 them in module_exit() functions.
100
101 A good practice might be to remove shadow
102 callback. It is called only when the livep
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.