Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752165AbbBVTSK (ORCPT ); Sun, 22 Feb 2015 14:18:10 -0500 Received: from cantor2.suse.de ([195.135.220.15]:34526 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752056AbbBVTSI (ORCPT ); Sun, 22 Feb 2015 14:18:08 -0500 Date: Sun, 22 Feb 2015 20:18:06 +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 , live-patching@vger.kernel.org Subject: Re: live patching design (was: Re: [PATCH 1/3] sched: add sched_task_call()) In-Reply-To: <20150222101737.GA24570@gmail.com> Message-ID: References: <20150220095003.GA23506@gmail.com> <20150220104418.GD25076@gmail.com> <20150220194901.GB3603@gmail.com> <20150220214613.GA21598@suse.com> <20150220220845.GI15980@treble.redhat.com> <20150221183005.GB8406@gmail.com> <20150222101737.GA24570@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: 1725 Lines: 39 [ live-patching@ ML added to CC here as well ] On Sun, 22 Feb 2015, Ingo Molnar wrote: > > BTW how exactly do you envision this will work? Do I understand your > > proposal correctly that EINTR will be "handled" somewhere in the "live > > patching special signal handler" and then have the interrupted syscall > > restarted? > > If you want to think about it in signal handling terms then it's a new > automatic in-kernel handler, which does not actually return back to > user-mode at all. > > We can do it via the signals machinery (mainly to reuse all the existing > signal_pending() code in various syscalls), or via new TIF flags like > the user work machinery: the principle is the same: interrupt out of > syscall functions into a central place and restart them, and return to > user-space later on as if a single call had been performed. > > This necessarily means some changes to syscalls, but not insurmountable > ones - and checkpoint/restore support would want to have similar changes > in any case so we can hit two birds with the same stone. Understood. I think this by itself really would be a huge improvement on how to force tasks to converge to the new universe without confusing the userspace via artificial signals (i.e. even with the lazy migration aproaches, without full serialization checkpoint). As I said yesterday, I am pretty sure we'll experiment with this in kgraft. Thanks for bringing this idea up, -- 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/