Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965199AbdGTRER (ORCPT ); Thu, 20 Jul 2017 13:04:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50326 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934523AbdGTREP (ORCPT ); Thu, 20 Jul 2017 13:04:15 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9869B80C03 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jpoimboe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9869B80C03 Date: Thu, 20 Jul 2017 12:04:12 -0500 From: Josh Poimboeuf To: Petr Mladek Cc: Joe Lawrence , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Jessica Yu , Jiri Kosina , Miroslav Benes , Chris J Arges Subject: Re: [PATCH] livepatch: add (un)patch hooks Message-ID: <20170720170412.amkpdaqx57jwo2ux@treble> References: <1499868600-10176-1-git-send-email-joe.lawrence@redhat.com> <1499868600-10176-2-git-send-email-joe.lawrence@redhat.com> <20170717155144.GF32632@pathway.suse.cz> <20170719204952.4fyhtig3rbw7z4w4@treble> <20170720041723.35r6qk2fia7xix3t@treble> <20170720155004.GB13895@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170720155004.GB13895@pathway.suse.cz> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 20 Jul 2017 17:04:15 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1353 Lines: 32 On Thu, Jul 20, 2017 at 05:50:04PM +0200, Petr Mladek wrote: > On Wed 2017-07-19 23:17:23, Josh Poimboeuf wrote: > > - patching otherwise unpatchable code (i.e., assembly) > > > > In many/most cases, it seems like stop_machine() would be very useful > > to avoid concurrency issues. > > I am not sure if stop_machine() would help here. It would make sense > in kPatch where also the ftrace handlers are added during > stop_machine(). Then it is possible to synchronize both operations > (hooks, enabling ftrace handlers) and do everything "atomically". > > IMHO, the big advantage of livepatch framework is that stop_machine() > is not needed. I hope that it will stay this way. > > Also it might need some additional support. You would want to stop > the machine to make sure that it is safe to do a change. Then > we might need to check stacks, ... Don't worry. I much prefer our current consistency model to kpatch, and I have no intention of changing it :-) That said, for the hooks, I still think stop_machine() will be helpful in some cases where you need to ensure no other code is running. Like the stack_segment patch I posted, for example. Anyway I'm not suggesting we do the stop_machine() in livepatch code itself. I'm just hoping it will work from a hook, in case the patch author needs to do it as a last resort. -- Josh