Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751834AbbBUS5p (ORCPT ); Sat, 21 Feb 2015 13:57:45 -0500 Received: from cantor2.suse.de ([195.135.220.15]:46268 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751448AbbBUS5m (ORCPT ); Sat, 21 Feb 2015 13:57:42 -0500 Date: Sat, 21 Feb 2015 19:57:39 +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: <20150221181852.GA8406@gmail.com> Message-ID: References: <20150219204036.GA16882@suse.com> <20150219214229.GD15980@treble.redhat.com> <20150220095003.GA23506@gmail.com> <20150220104418.GD25076@gmail.com> <20150220194901.GB3603@gmail.com> <20150220214613.GA21598@suse.com> <20150221181852.GA8406@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: 1724 Lines: 39 On Sat, 21 Feb 2015, Ingo Molnar wrote: > > This means that each and every sleeping task in the system has to be > > woken up in some way (sending a signal ...) to exit from a syscall it > > is sleeping in. Same for CPU hogs. All kernel threads need to be > > parked. > > Yes - although I'd not use signals for this, signals have > side effects - but yes, something functionally equivalent. This is similar to my proposal I came up with not too long time ago; a fake signal (analogically to, but not exactly the same, what freezer is using), that will just make tasks cycle through userspace/kernelspace boundary without other side-effects. > > This is exactly what you need to do for kGraft to complete patching. > > My understanding of kGraft is that by default you allow tasks to > continue 'in the new universe' after they are patched. Has this changed > or have I misunderstood the concept? What Vojtech meant here, I believe, is that the effort you have to make to force all tasks to queue themselves to park them on a safe place and then restart their execution is exactly the same as the effort you have to make to make kGraft converge and succeed. 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. -- 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/