Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753248AbbBRVCs (ORCPT ); Wed, 18 Feb 2015 16:02:48 -0500 Received: from jablonecka.jablonka.cz ([91.219.244.36]:51996 "EHLO jablonecka.jablonka.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751634AbbBRVCf (ORCPT ); Wed, 18 Feb 2015 16:02:35 -0500 X-Greylist: delayed 1063 seconds by postgrey-1.27 at vger.kernel.org; Wed, 18 Feb 2015 16:02:34 EST Date: Wed, 18 Feb 2015 21:44:44 +0100 From: Vojtech Pavlik To: Ingo Molnar Cc: Jiri Kosina , Peter Zijlstra , Josh Poimboeuf , Ingo Molnar , Masami Hiramatsu , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Seth Jennings Subject: Re: [RFC PATCH 6/9] livepatch: create per-task consistency model Message-ID: <20150218204444.GA7416@suse.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> <20150218201755.GA20097@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150218201755.GA20097@gmail.com> X-Bounce-Cookie: It's a lemon tree, dear Watson! User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2874 Lines: 70 On Wed, Feb 18, 2015 at 09:17:55PM +0100, Ingo Molnar wrote: > > * 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? For live patching it doesn't matter whether code is running, sleeping or frozen. What matters is whether there is state before patching that may not be valid after patching. For userspace tasks, the exit from a syscall is a perfect moment for switching to the "after" state, as all stacks, and thus all local variables are gone and no local state exists in the kernel for the thread. The freezer is a logical choice for kernel threads, however, given that kernel threads have no defined entry/exit point and execute within a single main function, local variables stay and thus local state persists from before to after freezing. Defining that no local state within a kernel thread may be relied upon after exiting from the freezer is certainly possible, and is already true for many kernel threads. It isn't a given property of the freezer itself, though. And isn't obvious for author of new kernel threads either. The ideal solution would be to convert the majority of kernel threads to workqueues, because then there is a defined entry/exit point over which state isn't transferred. That is a lot of work, though, and has other drawbacks, particularly in the realtime space. -- Vojtech Pavlik Director 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/