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 -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
