Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756616AbcDGPIU (ORCPT ); Thu, 7 Apr 2016 11:08:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34537 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756578AbcDGPIQ (ORCPT ); Thu, 7 Apr 2016 11:08:16 -0400 Date: Thu, 7 Apr 2016 10:08:14 -0500 From: Josh Poimboeuf To: Petr Mladek Cc: Jiri Kosina , 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: <20160407150814.tgihh5v6ydhvo7h6@treble.redhat.com> References: <20160407121030.GC27670@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160407121030.GC27670@pathway.suse.cz> 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: 1332 Lines: 37 On Thu, Apr 07, 2016 at 02:10:30PM +0200, Petr Mladek wrote: > On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote: > > TODO: > > - try ftrace handler switching idea from v1 cover letter > > I have had a discussion about it with Mirek. This would help with > kthreads. If they are sleeping in a patched function, we wake > them up, this will help to migrate them before they get asleep again. > > But it might be quite tricky. We must make sure to avoid a deadlock. I assume a deadlock could only occur if the function is changing locking semantics, and it's up to the patch author to be careful? Or did I miss the point? > We probably should not check the stack in atomic context Can you elaborate why not? Regardless, this might be fine, if the only goal of this approach is to transition kthreads (which I think it is). > or in time sensitive functions. Would it be up to the patch author to make this judgement? > An alternative would be to check the stack and try migration > when the process goes into a sleep. It is a location where > we should not be afraid of any deadlocks or slight delay. > There should be high changes for a successful migration with > a minimal impact on the system throughput. But if it's sleeping on a patched function as postulated above, that doesn't solve the stated problem :-) -- Josh