Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752136AbbBVTNc (ORCPT ); Sun, 22 Feb 2015 14:13:32 -0500 Received: from cantor2.suse.de ([195.135.220.15]:34388 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751996AbbBVTNb (ORCPT ); Sun, 22 Feb 2015 14:13:31 -0500 Date: Sun, 22 Feb 2015 20:13:28 +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 , Arjan van de Ven , Thomas Gleixner , Peter Zijlstra , Borislav Petkov , live-patching@vger.kernel.org Subject: Re: live kernel upgrades (was: live kernel patching design) In-Reply-To: <20150222104841.GA25335@gmail.com> Message-ID: References: <20150220194901.GB3603@gmail.com> <20150220214613.GA21598@suse.com> <20150221181852.GA8406@gmail.com> <20150221191607.GA9534@gmail.com> <20150221194840.GA10126@gmail.com> <20150222084601.GA23491@gmail.com> <20150222094639.GA23684@gmail.com> <20150222104841.GA25335@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: 1835 Lines: 43 [ added live-patching@ ML as well, in consistency with Josh ] On Sun, 22 Feb 2015, Ingo Molnar wrote: > It's all still tons of work to pull off a 'live kernel upgrade' on > native hardware, but IMHO it's tons of very useful work that helps a > dozen non-competing projects, literally. Yes, I agree, it might be nice-to-have feature. The only issue with that is that it's solving a completely different problem than live patching. Guys working on criu have made quite a few steps in that direction of already course; modulo bugs and current implementation limitations, you should be able to checkpoint your userspace, kexec to a new kernel, and restart your userspace. But if you ask the folks who are hungry for live bug patching, they wouldn't care. You mentioned "10 seconds", that's more or less equal to infinity to them. And frankly, even "10 seconds" is something we can't really guarantee. We could optimize the kernel the craziest way we can, but hardware takes its time to reinitialize. And in most cases, you'd really need to reinitalize it; I don't see a way how you could safely suspend it somehow in the old kernel and resume it in a new one, because the driver suspending the device might be completely different than the driver resuming the device. How are you able to provide hard guarantees that this is going to work? So all in all, if you ask me -- yes, live kernel upgrades from v3.20 to v3.21, pretty cool feature. Is it related to the problem we are after with live bug patching? I very much don't think so. Thanks, -- 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/