Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752790AbbBSJxF (ORCPT ); Thu, 19 Feb 2015 04:53:05 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:50460 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752125AbbBSJxC (ORCPT ); Thu, 19 Feb 2015 04:53:02 -0500 Date: Thu, 19 Feb 2015 10:52:51 +0100 From: Peter Zijlstra To: Vojtech Pavlik Cc: Ingo Molnar , Jiri Kosina , 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: <20150219095251.GE5029@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> <20150212130817.GV23123@twins.programming.kicks-ass.net> <20150218201755.GA20097@gmail.com> <20150218204444.GA7416@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150218204444.GA7416@suse.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: 1611 Lines: 35 On Wed, Feb 18, 2015 at 09:44:44PM +0100, Vojtech Pavlik wrote: > 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. kthread_park() functionality seems to be exactly what you want. -- 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/