From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753801AbbCJVaz (ORCPT ); Tue, 10 Mar 2015 17:30:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42246 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753773AbbCJVat (ORCPT ); Tue, 10 Mar 2015 17:30:49 -0400 Date: Tue, 10 Mar 2015 16:30:17 -0500 From: Josh Poimboeuf To: Jiri Kosina Cc: Seth Jennings , Vojtech Pavlik , Masami Hiramatsu , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar , jslaby@suse.cz, mbenes@suse.cz Subject: Re: [RFC PATCH 0/9] livepatch: consistency model Message-ID: <20150310213017.GA14122@treble.redhat.com> References: <20150310162319.GN10815@treble.redhat.com> 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 Tue, Mar 10, 2015 at 05:02:20PM -0400, Jiri Kosina wrote: > On Tue, 10 Mar 2015, Josh Poimboeuf wrote: > > > 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. > > Thanks for the update. Just FYI, in parallel, Jiri Slaby (with help from a > few other people) (added to CC) is working on RFC on a per-thread patching > on top of the livepatching core, so that we can actually compare pros and > cons of both aproaches and implementations. > > It might still take some time before its finalized and sent out as a RFC, > as I'd like it to also contain the "fake signal" task handling suggested > by Ingo. Miroslav is working on that part. Ok, thanks for the heads up. I think the two approaches are complementary. _If_ we can make stack checking safe, then IMO it's by far the most lightweight and least disruptive option, so it should be the first wave of attack. We can use that to transition most of the tasks. Any remaining "straggler" tasks (which are either sleeping on a patched function or have a potentially unreliable stack) can use something else like fake signals. -- Josh