From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932308AbbCJQXy (ORCPT ); Tue, 10 Mar 2015 12:23:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49595 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932153AbbCJQXv (ORCPT ); Tue, 10 Mar 2015 12:23:51 -0400 Date: Tue, 10 Mar 2015 11:23:19 -0500 From: Josh Poimboeuf To: Seth Jennings , Jiri Kosina , Vojtech Pavlik Cc: Masami Hiramatsu , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar Subject: Re: [RFC PATCH 0/9] livepatch: consistency model Message-ID: <20150310162319.GN10815@treble.redhat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 09, 2015 at 11:31:12AM -0600, Josh Poimboeuf wrote: > This patch set implements a livepatch consistency model, targeted for 3.21. > Now that we have a solid livepatch code base, this is the biggest remaining > missing piece. > > This code stems from the design proposal made by Vojtech [1] in November. It > makes live patching safer in general. Specifically, it allows you to apply > patches which change function prototypes. It also lays the groundwork for > future code changes which will enable data and data semantic changes. > > It's basically a hybrid of kpatch and kGraft, combining kpatch's backtrace > checking with kGraft's per-task consistency. When patching, tasks are > carefully transitioned from the old universe to the new universe. A task can > only be switched to the new universe if it's not using a function that is to be > patched or unpatched. After all tasks have moved to the new universe, the > patching process is complete. [...] Just an update on the status of this RFC. Thanks to everybody for all the useful comments. I plan to incorporate the resulting changes in an eventual v2 of this patch set. But, as Peter and Ingo have pointed out, stack traces are indeed unreliable. I have some ideas about how to improve them, coming soon in another RFC, which will be a prerequisite for this patch set. -- Josh