[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.2.21.1710191513130.21219@san.suse.cz>
Date: Thu, 19 Oct 2017 15:24:51 +0200 (CEST)
From: Miroslav Benes <mbenes@...e.cz>
To: Josh Poimboeuf <jpoimboe@...hat.com>
cc: Joao Moreira <jmoreira@...e.de>, live-patching@...r.kernel.org,
linux-kernel@...r.kernel.org, mmarek@...e.cz, pmladek@...e.com,
jikos@...e.cz, nstange@...e.de, jroedel@...e.de, matz@...e.de,
khlebnikov@...dex-team.ru, jeyu@...nel.org
Subject: Re: [PATCH 0/8] livepatch: klp-convert tool
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.
> 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.
We also considered complete source-based solution. Nicolai Stange works on
that (or at least on something which would make it possible).
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?
> > 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.
Miroslav
Powered by blists - more mailing lists