Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752210AbbBUTbz (ORCPT ); Sat, 21 Feb 2015 14:31:55 -0500 Received: from cantor2.suse.de ([195.135.220.15]:47361 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751680AbbBUTbw (ORCPT ); Sat, 21 Feb 2015 14:31:52 -0500 Date: Sat, 21 Feb 2015 20:31:48 +0100 (CET) From: Jiri Kosina To: Ingo Molnar 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()) In-Reply-To: <20150221191607.GA9534@gmail.com> Message-ID: 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> 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: 2319 Lines: 57 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 (*). 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. Or think of patching __notrace__ functions. 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). This is exactly why we came up with consistency models -- it allows you to draw the line at well-defined places. (*) there are some rather crazy ideas how to make this work, but the price you pay is basically always unacceptable slowdown Thanks, -- 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/