On Thu, 14 Apr 2016, Jessica Yu wrote: > +++ Miroslav Benes [14/04/16 15:28 +0200]: > > On Wed, 13 Apr 2016, Jessica Yu wrote: > > > > A second concern I have is that apply_relocate_add() relies on > > > sections like .stubs and .toc (for 64-bit) and .init.plt and .plt > > > sections (for 32-bit). In order for apply_relocate_add() to work for > > > livepatch, we must make sure these sections aren't thrown away and are > > > not in init module memory since this memory will be freed at the end > > > of module load (see how INIT_OFFSET_MASK is used in kernel/module.c). > > > As long as these sections are placed in module core memory, we will be > > > OK. I need to think about this a bit more. > > > > I knew I shouldn't have opened arch/powerpc/kernel/module*.c. > > > > We could always hack sh_flags of those sections in > > module_arch_frob_sections() to make them stay. > > > > I think we are fine here too. The onus would be on the patch build > tool (e.g., kpatch) to set the sh_flags to SHF_ALLOC, like we > already do to keep the klp relocation sections in memory :-) Yes, this is probably the best way. > For the 32-bit module code, I don't believe we would need to preserve > the .init.plt section for livepatch's call to apply_relocate_add(), > since relocations to init sections should've been applied during > module initialization, and we don't patch those types of functions. > Please correct me if my understanding is off. I think you are right, but I also think we don't have to worry about 32-bit powerpc anyway. This patch set supports ppc64le only so we can leave it for now. 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
