Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752075AbbBUSS7 (ORCPT ); Sat, 21 Feb 2015 13:18:59 -0500 Received: from mail-wg0-f47.google.com ([74.125.82.47]:46282 "EHLO mail-wg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751669AbbBUSS5 (ORCPT ); Sat, 21 Feb 2015 13:18:57 -0500 Date: Sat, 21 Feb 2015 19:18:52 +0100 From: Ingo Molnar To: Vojtech Pavlik Cc: Jiri Kosina , 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()) Message-ID: <20150221181852.GA8406@gmail.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150220214613.GA21598@suse.com> 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: 2418 Lines: 66 * Vojtech Pavlik wrote: > On Fri, Feb 20, 2015 at 08:49:01PM +0100, Ingo Molnar wrote: > > > > ... 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. > > Can you suggest a way how they would interfere? The > transition happens on entering or returning from a > syscall, there is no influence between individual tasks. Well, a 'new' task does not stop executing after returning from the syscall, right? If it's stopped (until all patching is totally complete) then you are right and I concede your point. If it's allowed to continue its workload then my point stands: subsequent execution of 'new' tasks can interfere with, slow down, interact with 'old' tasks trying to get patched. > > 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. > > The 'simple' method has to catch and freeze all tasks one > by one in syscall entry/exit, at the kernel/userspace > boundary, until all are frozen and then patch the system > atomically. Correct. > 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 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? 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/