On Mon, Apr 20, 2020 at 03:49:00PM -0400, Joe Lawrence wrote: > On Mon, Apr 20, 2020 at 02:11:17PM -0500, Josh Poimboeuf wrote: > > On Mon, Apr 20, 2020 at 03:01:41PM -0400, Joe Lawrence wrote: > > > > > ... apply_relocations() is also iterating over the section headers (the > > > > > diff context doesn't show it here, but i is an incrementing index over > > > > > sechdrs[]). > > > > > > > > > > So if there is more than one KLP relocation section, we'll process them > > > > > multiple times. At least the x86 relocation code will detect this and > > > > > fail the module load with an invalid relocation (existing value not > > > > > zero). > > > > > > > > Ah, yes, good catch! > > > > > > > > > > The same test case passed with a small modification to push the foreach > > > KLP section part to a kernel/livepatch/core.c local function and > > > exposing the klp_resolve_symbols() + apply_relocate_add() for a given > > > section to kernel/module.c. Something like following... > > > > I came up with something very similar, though I named them > > klp_apply_object_relocs() and klp_apply_section_relocs() and changed the > > argument order a bit (module first). Since it sounds like you have a > > test, could you try this one? > > > > LGTM. I have a few klp-convert selftests that I've been slowly > tinkering on and they all load/run successfully with this version. :) Good to hear, thanks! Hooray selftests :-) -- Josh
