Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755357AbbBTTtI (ORCPT ); Fri, 20 Feb 2015 14:49:08 -0500 Received: from mail-wg0-f46.google.com ([74.125.82.46]:35807 "EHLO mail-wg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752566AbbBTTtG (ORCPT ); Fri, 20 Feb 2015 14:49:06 -0500 Date: Fri, 20 Feb 2015 20:49:01 +0100 From: Ingo Molnar To: Jiri Kosina 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()) Message-ID: <20150220194901.GB3603@gmail.com> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2108 Lines: 54 * Jiri Kosina wrote: > > 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. That statement is false: an 'intermediate state' system where 'new' tasks are still running is still running and will interfere with the resolution of 'old' tasks. > 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. I think you misunderstood: the 'simple' method I outlined does not just 'synchronize', it actually executes the live patching atomically, once all tasks are gathered and we know they are _all_ in a safe state. I.e. it's in essence the strong stop-all atomic patching model of 'kpatch', combined with the reliable avoidance of kernel stacks that 'kgraft' uses. That should be the starting point, because it's the most reliable method. Thanks, Ingo -- 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/