On Thu, 12 Nov 2015, Josh Poimboeuf wrote: > On Thu, Nov 12, 2015 at 03:22:44PM -0500, Jessica Yu wrote: > > Looking into this more, I think we do need one __klp_rela section per > > function being patched. Each rela section is linked to the section to > > which the relocations apply via the rela section's sh_info field. In > > SHT_RELA sections, the sh_info field contains the section index to > > which the relocs apply. We cannot have one single combined rela > > section per object as the call to apply_relocate_add() simply won't > > work, because we would have relocs that apply to different functions > > (and hence different sections). > > > > So I guess instead of a single field in klp_object specifying the > > __klp_rela section index, we could probably just have an array of > > section indices. > > Ok, makes sense, sounds like we need multiple klp relas per object. Ok, it seems so. > I still don't quite understand the benefit of caching the klp_rela > section indices. What problem does it solve? It seems simpler to just > iterate over all the sections in klp_write_object_relocations(). It was just my need to be efficient and I think it would have made sense with only one dynrela section per object. An array of indices is "ugly" so I am all for iteration over all the sections in klp_write_object_relocations(). Miroslav -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
