Re: Fix issue with alternatives/paravirt patches

[Miroslav Benes]

On Thu, 21 Jul 2016, Jessica Yu wrote:

> +++ Miroslav Benes [12/07/16 14:06 +0200]:
> > 
> > Is there a problem when you need to generate a dynrela for paravirt code?
> > I mean one does not know during the build of a patch module if paravirt
> > would or would not be applied. If such code needs to be relocated it could
> > be a problem for kpatch-build. Is this correct or am I missing something?
> 
> In kpatch-build, "special" sections like .parainstructions and
> .altinstructions are into consideration. These sections are included
> in the final patch module if they reference any of the new replacement
> code. Like with any other section, kpatch-build will convert any relas
> from .rela.parainstructions (for example) to dynrelas if it is
> necessary.  And with this patch we apply all "dynrelas" (which are now
> actual relas in .klp.rela sections) first before applying any
> paravirt/alternatives patches in arch_klp_init_object_loaded(), which
> is the correct order.

Ah, right. So it should be ok.

> > Now the other architectures we support. s390 should be ok. There is
> > nothing much in module_finalize() there. powerpc is different though. It
> > is quite similar to x86_64 case. And also arm64 needs to be handled in
> > future.
> 
> Yeah, I think we are OK for s390, arm64 looks fairly straightforward
> (just a call to apply_alternatives()), powerpc looks slightly more
> involved but I haven't thoroughly dug into it yet.
> 
> So other arches will need to have arch_klp_init_object_loaded()
> implemented eventually (if needed), but I think it is fine for now to
> fix this issue on x86 first, since that's where the original bug
> cropped up.

Agreed.

Miroslav