Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756390AbbBLOVG (ORCPT ); Thu, 12 Feb 2015 09:21:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51281 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755899AbbBLOVD (ORCPT ); Thu, 12 Feb 2015 09:21:03 -0500 Date: Thu, 12 Feb 2015 08:20:35 -0600 From: Josh Poimboeuf To: Jiri Kosina Cc: Peter Zijlstra , 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 Message-ID: <20150212142035.GD18578@treble.redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2740 Lines: 72 On Thu, Feb 12, 2015 at 02:16:07PM +0100, Jiri Kosina wrote: > 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. Don't we have the same issue with livepatch? For example: while (some_condition) { ret = foo(); ... schedule(); <-- switch to the new universe while it's sleeps ... // use ret in an unexpected way } I think it's not really a problem, just something the patch author needs to be aware of regardless. It should be part of the checklist. You always need to be extremely careful when changing a function's return semantics. IIRC, when I looked at the freezer before, the biggest problems I found were that it's too disruptive to the process, and that not all kthreads are freezable. And I don't see anything inherently safer about it compared to just stack checking. -- Josh -- 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/