From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754487AbdJSODt (ORCPT ); Thu, 19 Oct 2017 10:03:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46610 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753295AbdJSODq (ORCPT ); Thu, 19 Oct 2017 10:03:46 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com CA005C04BD4E Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jpoimboe@redhat.com Date: Thu, 19 Oct 2017 09:03:38 -0500 From: Josh Poimboeuf To: Miroslav Benes Cc: Joao Moreira , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, mmarek@suse.cz, 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: <20171019140338.pngwewyzllaw2wu5@treble> References: <20170829190140.401-1-jmoreira@suse.de> <20170830180025.3s5tscqf5isqwg5n@treble> <20171011024615.y55lwbgpgo6b5dll@treble> <14124e34-04f7-950e-72fb-64f13e62f57e@suse.de> <20171019130146.uxjuhgn2t3yavgz2@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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.31]); Thu, 19 Oct 2017 14:03:46 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 19, 2017 at 03:24:51PM +0200, Miroslav Benes wrote: > On Thu, 19 Oct 2017, Josh Poimboeuf wrote: > > > On Wed, Oct 11, 2017 at 09:42:09AM -0300, Joao Moreira wrote: > > > > Sounds good! For klp-convert to be successful, we really need a > > > > strategy for dealing with such optimizations. I'm thinking that a > > > > '-fpreserve-function-abi' flag would be the cleanest way to handle it. > > > > > > > > If we don't have a strategy for dealing with optimizations, then we may > > > > instead need to go with a binary diff-based tool like kpatch-build. > > > > > > I'm currently looking into binary diff-based solutions to deal with this > > > problem. My plan is to submit a second patch set once I have it functional > > > and land both things (klp-convert and bin-diff) in two different steps. > > > > Instead of having multiple approaches, I'd strongly prefer that we > > converge on a single in-tree approach that works for everybody. > > > > (Whether that will be source-based like klp-convert or binary-based like > > kpatch-build, I don't know.) > > I think that klp-convert can work with both. Even with non-source-based > solution you need something to generate those relocation records. I > consider klp-convert as a part of the building pipeline. Hm. If I understand correctly, the binary diff tool (or some tool in the pipeline) would create the .klp.module_relocs.* section, and then klp-convert would convert that to the .klp.sym.* and .klp.rela.* sections which livepatch needs. But if the original tool is creating a relocation section, can't it instead just create the livepatch .klp.* sections directly? What's the benefit of the extra conversion step? > > BTW, what is bin-diff? Have you seen kpatch-build? > > I'm speaking for Joao here, but we discussed this personally and I think > he meant approach based on asmtool > (https://github.com/joergroedel/asmtool). We'd like to explore as much as > possible. Ok, I'd be interested in seeing that, and also what its benefits are compared to kpatch-build. > We also considered complete source-based solution. Nicolai Stange works on > that (or at least on something which would make it possible). What is a complete source-based solution? Is it just "klp-convert + some GCC optimization strategy" or is it something more? > We can decide what to have in upstream afterwards. But I still think that > klp-convert will be part of it in some form. Am I missing something? I guess it really depends on what the solution looks like. If we decided on kpatch-build (or some variation of its tooling) then we might not need klp-convert. > > > Is there any issue with following this schedule? Meaning, do you guys still > > > plan on reviewing this patch set or do you prefer me to do something > > > differently in terms of approach? > > > > IMO, klp-convert will only be useful if we have a realistic strategy for > > dealing with GCC optimizations. So I'd say we should follow through on > > that with the compiler folks before spending too much more time on it. > > Yes, I'm all for a solution on GCC side, but that may take a while and > even then it is still a huge step to get it into a distribution (we have > GCC 4.8.5 in SLE12 :)). > > However, there is an easy temporary solution. You can add all > referenced optimized functions to a livepatch and let klp-convert process > the rest. How do you find all referenced optimized functions? -- Josh