Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755675AbbBLNIY (ORCPT ); Thu, 12 Feb 2015 08:08:24 -0500 Received: from casper.infradead.org ([85.118.1.10]:43931 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755385AbbBLNIW (ORCPT ); Thu, 12 Feb 2015 08:08:22 -0500 Date: Thu, 12 Feb 2015 14:08:17 +0100 From: Peter Zijlstra To: Josh Poimboeuf Cc: Ingo Molnar , Masami Hiramatsu , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Seth Jennings , Jiri Kosina , Vojtech Pavlik Subject: Re: [RFC PATCH 6/9] livepatch: create per-task consistency model Message-ID: <20150212130817.GV23123@twins.programming.kicks-ass.net> References: <2c3d1e685dae5cccc2dfdb1b24c241b2f1c89348.1423499826.git.jpoimboe@redhat.com> <20150212032121.GA18578@treble.redhat.com> <20150212115628.GL2896@worktop.programming.kicks-ass.net> <20150212125149.GB18578@treble.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150212125149.GB18578@treble.redhat.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1372 Lines: 28 On Thu, Feb 12, 2015 at 06:51:49AM -0600, Josh Poimboeuf wrote: > > > To provide some background, I'm looking for a way to temporarily prevent > > > a sleeping task from running while its stack is examined, to decide > > > whether it can be safely switched to the new patching "universe". For > > > more details see klp_transition_task() in the patch below. > > > > > > Using task_rq_lock() is the most straightforward way I could find to > > > achieve that. > > > > Its not at all clear how all this would work to me. And I'm not > > motivated enough to go try and reverse engineer your patch; > > 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. And what's wrong with using known good spots like the freezer? -- 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/