From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934346AbdAFOyR (ORCPT ); Fri, 6 Jan 2017 09:54:17 -0500 Received: from mx2.suse.de ([195.135.220.15]:52889 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934255AbdAFOxw (ORCPT ); Fri, 6 Jan 2017 09:53:52 -0500 From: Miroslav Benes To: jpoimboe@redhat.com, jeyu@redhat.com, jikos@kernel.org Cc: pmladek@suse.com, corbet@lwn.net, live-patching@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Miroslav Benes Subject: [PATCH] Documentation/livepatch: remove the limitation for schedule() patching Date: Fri, 6 Jan 2017 15:00:45 +0100 Message-Id: <20170106140045.26331-1-mbenes@suse.cz> X-Mailer: git-send-email 2.11.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- FWIW, I also tested this to be sure on top of the consistency model patch set. I patched schedule() function which calls __schedule() (it is impossible to patch it directly due to notrace attribute). It works well except... 1. the patching process does not finish, because many tasks sleep in schedule. STOP/CONT signal does not help. I'll investigate. 2. reversion of the process does not work as expected. The kernel crashes after the removal of the module. A task very likely slept in schedule and was not migrated properly. It might be because of the races in klp_reverse_transition() described by Petr, or might be somewhere else. I'll look into it. Documentation/livepatch/livepatch.txt | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/Documentation/livepatch/livepatch.txt b/Documentation/livepatch/livepatch.txt index f5967316deb9..7f04e13ec53d 100644 --- a/Documentation/livepatch/livepatch.txt +++ b/Documentation/livepatch/livepatch.txt @@ -329,25 +329,6 @@ See Documentation/ABI/testing/sysfs-kernel-livepatch for more details. 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 -- 2.11.0