From: Miroslav Benes Date: Fri, 6 Jan 2017 14:00:45 +0000 (+0100) Subject: livepatch: doc: remove the limitation for schedule() patching X-Git-Tag: v5.15~11882^2 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=372e2db7210df7c45ead46429aeb1443ba148060;p=platform%2Fkernel%2Flinux-starfive.git livepatch: doc: remove the limitation for schedule() patching The Limitations section of the documentation describes the impossibility to livepatch anything that is inlined to __schedule() function. This had been true till 4.9 kernel came. Thanks to commit 0100301bfdf5 ("sched/x86: Rewrite the switch_to() code") from Brian Gerst there is __switch_to_asm function now (implemented in assembly) called properly from context_switch(). RIP is thus saved on the stack and a task would return to proper version of __schedule() et al. functions. Of course __switch_to_asm() is not patchable for the reason described in the section. But there is no __fentry__ call and I cannot imagine a reason to do it anyway. Therefore, remove the paragraphs from the section. Signed-off-by: Miroslav Benes Reviewed-by: Petr Mladek Acked-by: Josh Poimboeuf Signed-off-by: Jiri Kosina --- diff --git a/Documentation/livepatch/livepatch.txt b/Documentation/livepatch/livepatch.txt index f596731..7f04e13 100644 --- a/Documentation/livepatch/livepatch.txt +++ b/Documentation/livepatch/livepatch.txt @@ -329,25 +329,6 @@ The current Livepatch implementation has several limitations: by "notrace". - + Anything inlined into __schedule() can not be patched. - - The switch_to macro is inlined into __schedule(). It switches the - context between two processes in the middle of the macro. It does - not save RIP in x86_64 version (contrary to 32-bit version). Instead, - the currently used __schedule()/switch_to() handles both processes. - - Now, let's have two different tasks. One calls the original - __schedule(), its registers are stored in a defined order and it - goes to sleep in the switch_to macro and some other task is restored - using the original __schedule(). Then there is the second task which - calls patched__schedule(), it goes to sleep there and the first task - is picked by the patched__schedule(). Its RSP is restored and now - the registers should be restored as well. But the order is different - in the new patched__schedule(), so... - - There is work in progress to remove this limitation. - - + Livepatch modules can not be removed. The current implementation just redirects the functions at the very