summaryrefslogtreecommitdiff
path: root/Documentation/livepatch
diff options
context:
space:
mode:
authorPetr Mladek <pmladek@suse.com>2019-01-09 15:43:28 +0300
committerJiri Kosina <jkosina@suse.cz>2019-01-11 22:51:24 +0300
commitd67a53720966f2ef5be5c8f238d13512b8260868 (patch)
treef42526876b6b2d822611345dc219d514d60ef448 /Documentation/livepatch
parentc4e6874f2a2965e932f4a5cf2631bc6024e55021 (diff)
downloadlinux-d67a53720966f2ef5be5c8f238d13512b8260868.tar.xz
livepatch: Remove ordering (stacking) of the livepatches
The atomic replace and cumulative patches were introduced as a more secure way to handle dependent patches. They simplify the logic: + Any new cumulative patch is supposed to take over shadow variables and changes made by callbacks from previous livepatches. + All replaced patches are discarded and the modules can be unloaded. As a result, there is only one scenario when a cumulative livepatch gets disabled. The different handling of "normal" and cumulative patches might cause confusion. It would make sense to keep only one mode. On the other hand, it would be rude to enforce using the cumulative livepatches even for trivial and independent (hot) fixes. However, the stack of patches is not really necessary any longer. The patch ordering was never clearly visible via the sysfs interface. Also the "normal" patches need a lot of caution anyway. Note that the list of enabled patches is still necessary but the ordering is not longer enforced. Otherwise, the code is ready to disable livepatches in an random order. Namely, klp_check_stack_func() always looks for the function from the livepatch that is being disabled. klp_func structures are just removed from the related func_stack. Finally, the ftrace handlers is removed only when the func_stack becomes empty. Signed-off-by: Petr Mladek <pmladek@suse.com> Acked-by: Miroslav Benes <mbenes@suse.cz> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Diffstat (limited to 'Documentation/livepatch')
-rw-r--r--Documentation/livepatch/cumulative-patches.txt11
-rw-r--r--Documentation/livepatch/livepatch.txt13
2 files changed, 11 insertions, 13 deletions
diff --git a/Documentation/livepatch/cumulative-patches.txt b/Documentation/livepatch/cumulative-patches.txt
index e7cf5be69f23..0012808e8d44 100644
--- a/Documentation/livepatch/cumulative-patches.txt
+++ b/Documentation/livepatch/cumulative-patches.txt
@@ -7,8 +7,8 @@ to do different changes to the same function(s) then we need to define
an order in which the patches will be installed. And function implementations
from any newer livepatch must be done on top of the older ones.
-This might become a maintenance nightmare. Especially if anyone would want
-to remove a patch that is in the middle of the stack.
+This might become a maintenance nightmare. Especially when more patches
+modified the same function in different ways.
An elegant solution comes with the feature called "Atomic Replace". It allows
creation of so called "Cumulative Patches". They include all wanted changes
@@ -26,11 +26,9 @@ for example:
.replace = true,
};
-Such a patch is added on top of the livepatch stack when enabled.
-
All processes are then migrated to use the code only from the new patch.
Once the transition is finished, all older patches are automatically
-disabled and removed from the stack of patches.
+disabled.
Ftrace handlers are transparently removed from functions that are no
longer modified by the new cumulative patch.
@@ -57,8 +55,7 @@ The atomic replace allows:
+ Remove eventual performance impact caused by core redirection
for functions that are no longer patched.
- + Decrease user confusion about stacking order and what code
- is actually in use.
+ + Decrease user confusion about dependencies between livepatches.
Limitations:
diff --git a/Documentation/livepatch/livepatch.txt b/Documentation/livepatch/livepatch.txt
index 6f32d6ea2fcb..71d7f286ec4d 100644
--- a/Documentation/livepatch/livepatch.txt
+++ b/Documentation/livepatch/livepatch.txt
@@ -143,9 +143,9 @@ without HAVE_RELIABLE_STACKTRACE are not considered fully supported by
the kernel livepatching.
The /sys/kernel/livepatch/<patch>/transition file shows whether a patch
-is in transition. Only a single patch (the topmost patch on the stack)
-can be in transition at a given time. A patch can remain in transition
-indefinitely, if any of the tasks are stuck in the initial patch state.
+is in transition. Only a single patch can be in transition at a given
+time. A patch can remain in transition indefinitely, if any of the tasks
+are stuck in the initial patch state.
A transition can be reversed and effectively canceled by writing the
opposite value to the /sys/kernel/livepatch/<patch>/enabled file while
@@ -351,6 +351,10 @@ to '0'.
The right implementation is selected by the ftrace handler, see
the "Consistency model" section.
+ That said, it is highly recommended to use cumulative livepatches
+ because they help keeping the consistency of all changes. In this case,
+ functions might be patched two times only during the transition period.
+
5.3. Replacing
--------------
@@ -389,9 +393,6 @@ becomes empty.
Third, the sysfs interface is destroyed.
-Note that patches must be disabled in exactly the reverse order in which
-they were enabled. It makes the problem and the implementation much easier.
-
5.5. Removing
-------------