On Thu, Sep 05, 2019 at 02:03:34PM +0200, Miroslav Benes wrote: > > > + I would like to better understand the scope of the current > > > problems. It is about modifying code in the livepatch that > > > depends on position of the related code: > > > > > > + relocations are rather clear; we will need them anyway > > > to access non-public (static) API from the original code. > > > > > > + What are the other changes? > > > > I think the .klp.arch sections are the big ones: > > > > .klp.arch.altinstructions > > .klp.arch.parainstructions > > .klp.arch.jump_labels (doesn't exist yet) > > > > And that's just x86... > > I may misunderstand, but we have .klp.arch sections because para and > alternatives have to be processed after relocations. And if we cannot get > rid of relocations completely, because of static symbols, then we cannot > get rid of .klp.arch sections either. With late module patching gone, the module code can just process the klp relocations at the same time it processes normal relocations. Then the normal module alt/para/jump_label processing code can be used instead of arch_klp_init_object_loaded(). Note this also means that Joe's patches can remove copy_module_elf() and free_module_elf(). And module_arch_freeing_init() in s390. > > And then of course there's the klp coming/going notifiers which have > > also been an additional source of complexity. > > True, but I think we (me and Petr) do not consider it as much of a problem > as you. It's less of an issue than .klp.arch and all the related code which can be removed. -- Josh
