diff options
author | Petr Mladek | 2019-01-09 13:43:28 +0100 |
---|---|---|
committer | Jiri Kosina | 2019-01-11 20:51:24 +0100 |
commit | d67a53720966f2ef5be5c8f238d13512b8260868 (patch) | |
tree | f42526876b6b2d822611345dc219d514d60ef448 /Documentation/livepatch/livepatch.txt | |
parent | livepatch: Atomic replace and cumulative patches documentation (diff) | |
download | kernel-qcow2-linux-d67a53720966f2ef5be5c8f238d13512b8260868.tar.gz kernel-qcow2-linux-d67a53720966f2ef5be5c8f238d13512b8260868.tar.xz kernel-qcow2-linux-d67a53720966f2ef5be5c8f238d13512b8260868.zip |
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/livepatch.txt')
-rw-r--r-- | Documentation/livepatch/livepatch.txt | 13 |
1 files changed, 7 insertions, 6 deletions
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 ------------- |