Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754284AbbBTK6U (ORCPT ); Fri, 20 Feb 2015 05:58:20 -0500 Received: from cantor2.suse.de ([195.135.220.15]:50138 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753092AbbBTK6T (ORCPT ); Fri, 20 Feb 2015 05:58:19 -0500 Date: Fri, 20 Feb 2015 11:58:17 +0100 (CET) From: Jiri Kosina To: Ingo Molnar cc: Josh Poimboeuf , Vojtech Pavlik , 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: <20150220104418.GD25076@gmail.com> Message-ID: References: <20150219163359.GA25438@suse.cz> <20150219170353.GB15980@treble.redhat.com> <20150219171929.GA13178@suse.cz> <20150219173255.GC15980@treble.redhat.com> <20150219204036.GA16882@suse.com> <20150219214229.GD15980@treble.redhat.com> <20150220095003.GA23506@gmail.com> <20150220104418.GD25076@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: 2437 Lines: 58 On Fri, 20 Feb 2015, Ingo Molnar wrote: > - the complicated method spread out over time: uses the > same essential mechanism plus the ftrace patching > machinery to detect whether all tasks have transitioned > through a version flip. [this is what kgraft does in > part.] The only difference of this to what kgraft does is that alive-enough tasks are not put in this kind of "out of kernel 'freezer'", but keep running. Modifying kgraft to (optionally) add the synchronization barrier and then flip the switch should be a rather trivial task, and can indeed be added as a simple option to the patch author / sysadmin. However ... > All fundamental pieces of the simple method are necessary to get > guaranteed time transition from the complicated method: task tracking > and transparent catching of them, handling kthreads, etc. > > My argument is that the simple method should be implemented first and > foremost. > > Then people can do add-on features to possibly spread out the new > function versions in a more complicated way if they want to avoid the > stop-all-tasks transition - although I'm not convinced about it: I'm > sure sure many sysadmins would like the bug patching to be over with > quickly and not have their systems in an intermediate state like kgraft > does it. ... the choice the sysadmins have here is either have the system running in an intermediate state, or have the system completely dead for the *same time*. Because to finish the transition successfully, all the tasks have to be woken up in any case. (please note that this is different to suspend/resume task freezing, because we don't care about sleeping tasks there). But I do get your point; what you are basically saying is that your preference is what kgraft is doing, and option to allow for a global synchronization point should be added in parallel to the gradual lazy migration. > In any case, as per my arguments above, examining the kernel stack is > superfluous (so we won't be exposed to the fragility of it either): > there's no need to examine it and writing such patches is misguided... > > Thanks, > > Ingo > -- 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/