From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752595AbdJTOUO (ORCPT ); Fri, 20 Oct 2017 10:20:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34502 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751916AbdJTOUM (ORCPT ); Fri, 20 Oct 2017 10:20:12 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D5C2AA1007 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jpoimboe@redhat.com Date: Fri, 20 Oct 2017 09:20:09 -0500 From: Josh Poimboeuf To: Torsten Duwe Cc: Miroslav Benes , Joao Moreira , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, pmladek@suse.com, jikos@suse.cz, nstange@suse.de, jroedel@suse.de, matz@suse.de, khlebnikov@yandex-team.ru, jeyu@kernel.org Subject: Re: [PATCH 0/8] livepatch: klp-convert tool Message-ID: <20171020142009.hqnfuklf3l22noz2@treble> References: <14124e34-04f7-950e-72fb-64f13e62f57e@suse.de> <20171019130146.uxjuhgn2t3yavgz2@treble> <20171019140338.pngwewyzllaw2wu5@treble> <20171019151522.5ih3egvzr3wm3h7r@treble> <20171020124432.GB20306@lst.de> <20171020132432.majphjzzfrbcrdos@treble> <20171020134412.GA28905@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20171020134412.GA28905@lst.de> 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.25]); Fri, 20 Oct 2017 14:20:12 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 20, 2017 at 03:44:12PM +0200, Torsten Duwe wrote: > On Fri, Oct 20, 2017 at 08:24:32AM -0500, Josh Poimboeuf wrote: > > On Fri, Oct 20, 2017 at 02:44:32PM +0200, Torsten Duwe wrote: > > > I have a bad feeling about the IPA stuff in general. An obj-based approach > > > is cool in a way that it still works, and is sure to work, if the IPA > > > assumptions that led to the optimisations still hold, but as soon as they > > > break, you're screwed big time. > > > > Huh? The obj-based approach (e.g., kpatch, bin-diff) inherently detects > > such changes. Or am I misunderstanding? If so, please elaborate. > > If e.g. the old callee does not use a caller-saved reg, neither does the new > code, there is no reason to actually save it. IPA will detect this and spare > the reg save/restore. If now by any coincidence the new function needs that > register, what can you do? Patch all callers as well? You'll likely end up > with a far-too-big live patch or by coding something in assembler :-( Yes, you do have to patch the caller in that case. But kpatch-build detects that the caller changed as well, so both functions get patched and it's not a problem. And I don't remember ever seeing more than one caller for such a case. At least it's never been a problem so far. -- Josh