Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752206AbbBUTst (ORCPT ); Sat, 21 Feb 2015 14:48:49 -0500 Received: from mail-wi0-f172.google.com ([209.85.212.172]:46282 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751870AbbBUTsp (ORCPT ); Sat, 21 Feb 2015 14:48:45 -0500 Date: Sat, 21 Feb 2015 20:48:40 +0100 From: Ingo Molnar To: Jiri Kosina Cc: Vojtech Pavlik , Josh Poimboeuf , Peter Zijlstra , Andrew Morton , Ingo Molnar , Seth Jennings , linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: live patching design (was: Re: [PATCH 1/3] sched: add sched_task_call()) Message-ID: <20150221194840.GA10126@gmail.com> References: <20150220095003.GA23506@gmail.com> <20150220104418.GD25076@gmail.com> <20150220194901.GB3603@gmail.com> <20150220214613.GA21598@suse.com> <20150221181852.GA8406@gmail.com> <20150221191607.GA9534@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3234 Lines: 88 * Jiri Kosina wrote: > On Sat, 21 Feb 2015, Ingo Molnar wrote: > > > > But admittedly, if we reserve a special sort-of > > > signal for making the tasks pass through a safe > > > checkpoint (and make them queue there (your solution) > > > or make them just pass through it and continue > > > (current kGraft)), it might reduce the time this > > > effort needs considerably. > > > > Well, I think the 'simple' method has another > > advantage: it can only work if all those problems > > (kthreads, parking machinery) are solved, because the > > patching will occur only everything is quiescent. > > > > So no shortcuts are allowed, by design. It starts from > > a fundamentally safe, robust base, while all the other > > approaches I've seen were developed in a 'lets get the > > patching to work, then iteratively try to make it > > safer' which really puts the cart before the horse. > > > > So to put it more bluntly: I don't subscribe to the > > whole 'consistency model' nonsense: that's just crazy > > talk IMHO. > > > > Make it fundamentally safe from the very beginning, the > > 'simple method' I suggested _won't live patch the > > kernel_ if the mechanism has a bug and some kthread or > > task does not park. See the difference? > > I see the difference, but I am afraid you are simplifying > the situation a litle bit too much. > > There will always be properties of patches that will make > them unapplicable in a "live patching" way by design. > Think of data structure layout changes (*). Yes. > Or think of kernel that has some 3rd party vendor module > loaded, and this module spawning a ktrehad that is not > capable of parking itself. The kernel will refuse to live patch until the module is fixed. It is a win by any measure. > Or think of patching __notrace__ functions. Why would __notrace__ functions be a problem in the 'simple' method? Live patching with this method will work even if ftrace is not built in, we can just patch out the function in the simplest possible fashion, because we do it atomically and don't have to worry about per task 'transition state' - like kGraft does. It's a massive simplification and there's no need to rely on ftrace's mcount trick. (Sorry Steve!) > Etc. > > So it's not black and white, it's really a rather > philosophical question where to draw the line (and make > sure that everyone is aware of where the line is and what > it means). Out of the three examples you mentioned, two are actually an advantage to begin with - so I'd suggest you stop condescending me ... > This is exactly why we came up with consistency models -- > it allows you to draw the line at well-defined places. To still be blunt: they are snake oil, a bit like 'security modules': allowing upstream merges by consensus between competing pieces of crap, instead of coming up with a single good design that we can call the Linux kernel live patching method ... Thanks, Ingo -- 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/