Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757407AbcDGSDI (ORCPT ); Thu, 7 Apr 2016 14:03:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52882 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757297AbcDGSDF (ORCPT ); Thu, 7 Apr 2016 14:03:05 -0400 Date: Thu, 7 Apr 2016 13:03:02 -0500 From: Josh Poimboeuf To: Jiri Kosina Cc: Petr Mladek , Jessica Yu , Miroslav Benes , linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Vojtech Pavlik Subject: Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model Message-ID: <20160407180302.c5x3sj6b3ditizc4@treble.redhat.com> References: <20160407121030.GC27670@pathway.suse.cz> <20160407150814.tgihh5v6ydhvo7h6@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 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1709 Lines: 41 On Thu, Apr 07, 2016 at 05:47:00PM +0200, Jiri Kosina wrote: > On Thu, 7 Apr 2016, Josh Poimboeuf wrote: > > > > > - try ftrace handler switching idea from v1 cover letter > [ ... ] > > > We probably should not check the stack in atomic context > > > > Can you elaborate why not? > > I admittedly forgot what the "ftrace handler switching idea" is, and am > not sure where exactly to look for it (could you please point it to me so > that I can refresh my memory) Here's where I originally described it [1]: | 2) As mentioned above, kthreads which are always sleeping on a patched function | will never transition to the new universe. This is really a minor issue | (less than 1% of patches). It's not necessarily something that needs to be | resolved with this patch set, but it would be good to have some discussion | about it regardless. | | To overcome this issue, I have 1/2 an idea: we could add some stack checking | code to the ftrace handler itself to transition the kthread to the new | universe after it re-enters the function it was originally sleeping on, if | the stack doesn't already have have any other to-be-patched functions. | Combined with the klp_transition_work_fn()'s periodic stack checking of | sleeping tasks, that would handle most of the cases (except when trying to | patch the high-level thread_fn itself). > but generally we can't assume that a memory holding stack of a > sleeping task hasn't been reclaimed and wouldn't need to have been > paged in again. Hm, we're talking about kernel stacks, right? Are they not always resident in memory? [1] https://lkml.kernel.org/r/cover.1423499826.git.jpoimboe@redhat.com: -- Josh