Re: [PATCH 0/8] livepatch: klp-convert tool

[Josh Poimboeuf <jpoimboe@redhat.com>]

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