Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753085AbbBRUSD (ORCPT ); Wed, 18 Feb 2015 15:18:03 -0500 Received: from mail-wg0-f45.google.com ([74.125.82.45]:63323 "EHLO mail-wg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751531AbbBRUSB (ORCPT ); Wed, 18 Feb 2015 15:18:01 -0500 Date: Wed, 18 Feb 2015 21:17:55 +0100 From: Ingo Molnar To: Jiri Kosina Cc: Peter Zijlstra , 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 Message-ID: <20150218201755.GA20097@gmail.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=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: 1542 Lines: 41 * Jiri Kosina wrote: > On Thu, 12 Feb 2015, Peter Zijlstra wrote: > > > And what's wrong with using known good spots like the freezer? > > Quoting Tejun from the thread Jiri Slaby likely had on > mind: > > "The fact that they may coincide often can be useful as a > guideline or whatever but I'm completely against just > mushing it together when it isn't correct. This kind of > things quickly lead to ambiguous situations where people > are not sure about the specific semantics or guarantees > of the construct and implement weird voodoo code followed > by voodoo fixes. We already had a full round of that > with the kernel freezer itself, where people thought that > the freezer magically makes PM work properly for a > subsystem. Let's please not do that again." I don't follow this vague argument. The concept of 'freezing' all userspace execution is pretty unambiguous: tasks that are running are trapped out at known safe points such as context switch points or syscall entry. Once all tasks have stopped, the system is frozen in the sense that only the code we want is running, so you can run special code without worrying about races. What's the problem with that? Why would it be fundamentally unsuitable for live patching? 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/