Lines Matching +full:in +full:- +full:functions

7 an order in which the patches will be installed. And function implementations
11 modified the same function in different ways.
15 from all older livepatches and completely replace them in one transition.
18 -----
20 The atomic replace can be enabled by setting "replace" flag in struct klp_patch,
33 Ftrace handlers are transparently removed from functions that are no
42 actually in use. Also the livepatch might then be seen as a "normal"
48 --------
52   - Atomically revert some functions in a previous patch while
53     upgrading other functions.
55   - Remove eventual performance impact caused by core redirection
56     for functions that are no longer patched.
58   - Decrease user confusion about dependencies between livepatches.
62 ------------
64   - Once the operation finishes, there is no straightforward way
67     A good practice is to set .replace flag in any released livepatch.
68     Then re-adding an older livepatch is equivalent to downgrading
70     extra modifications in (un)patching callbacks or in the module_init()
71     or module_exit() functions, see below.
77   - Only the (un)patching callbacks from the _new_ cumulative livepatch are
80     In other words, the cumulative patch is responsible for doing any actions
86     This might be seen as a limitation in some scenarios. But it makes life
87     easier in many others. Only the new cumulative livepatch knows what
91     In any case, it would be a nightmare to think about the order of
96   - There is no special handling of shadow variables. Livepatch authors
99     them in module_exit() functions.
101     A good practice might be to remove shadow variables in the post-unpatch