Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755797AbbBLNQM (ORCPT ); Thu, 12 Feb 2015 08:16:12 -0500 Received: from cantor2.suse.de ([195.135.220.15]:34929 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755372AbbBLNQK (ORCPT ); Thu, 12 Feb 2015 08:16:10 -0500 Date: Thu, 12 Feb 2015 14:16:07 +0100 (CET) From: Jiri Kosina To: Peter Zijlstra cc: Josh Poimboeuf , Ingo Molnar , Masami Hiramatsu , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Seth Jennings , Vojtech Pavlik Subject: Re: [RFC PATCH 6/9] livepatch: create per-task consistency model In-Reply-To: <20150212130817.GV23123@twins.programming.kicks-ass.net> Message-ID: References: <2c3d1e685dae5cccc2dfdb1b24c241b2f1c89348.1423499826.git.jpoimboe@redhat.com> <20150212032121.GA18578@treble.redhat.com> <20150212115628.GL2896@worktop.programming.kicks-ass.net> <20150212125149.GB18578@treble.redhat.com> <20150212130817.GV23123@twins.programming.kicks-ass.net> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1934 Lines: 52 On Thu, 12 Feb 2015, Peter Zijlstra wrote: > > The short answer is: I need a way to ensure that a task isn't sleeping > > on any of the functions we're trying to patch. If it's not, then I can > > switch the task over to start using new versions of functions. > > > > Obviously, there are many more details than that. If you have specific > > questions I can try to answer them. > > How can one task run new and another task old functions? Once you patch > any indirect function pointer any task will see the new call. Patched functions are redirected through ftrace trampoline, and decision is being made there which function (old or new) to redirect to. Function calls through pointer always go first to the original function, and get redirected from its __fentry__ site. Once the system is in fully patched state, the overhead of the trampoline is reduced (no expensive decision-making to be made there, etc) to minimum. Sure, you will never be on a 100% of performance of the unpatched kernel for redirected functions, the indirect call through the trampoline will always be there (although ftrace with dynamic trampolines is really minimizing this penalty to few extra instructions, one extra call and one extra ret being the expensive ones). > And what's wrong with using known good spots like the freezer? It has undefined semantics when it comes to what you want to achieve here. Say for example you have a kernel thread which does something like while (some_condition) { ret = foo(); ... try_to_freeze(); ... } and you have a livepatch patching foo() and changing its return value semantics. Then freezer doesn't really help. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/