On Tue, Jul 14, 2015 at 04:36:35PM +0200, Miroslav Benes wrote: > To make it clear and avoid further confusion, you want to add one call to > simplify_symbols() (called from load_module()) to SHN_UNDEF processing. > This would handle all those unresolved symbols Right. > and thus there would be no > need to do it quite expensively in userspace (that is your > create-diff-object for example). Is that correct? Well, not exactly. I think most of the real benefits would be in the kernel. - removal of livepatch relocation code (which duplicates the kernel module relocation code) - livepatch becomes arch-independent (other than our reliance on certain arch-specific ftrace features) - removal of the complex klp module notifier stuff - kbuild based livepatch modules would achieve functional parity with kpatch-build based ones (and thus there is less need for a complex user space tool) > As you mention above this is bypassing of EXPORT_SYMBOL (and > EXPORT_SYMBOL_GPL) logic. This isn't anything new. We're already bypassing EXPORT_SYMBOL today with klp_write_module_reloc(). The proposal is to do it more sanely. > Even if we mark each relevant unresolved symbol > as for klp-only use there would be no obstacle for anyone else to do it. > If you come up with the solution that would bind this feature with klp > only we could discuss it more. But I am not sure otherwise. Well, it's already possible for any module to bypass EXPORT_SYMBOL today if they really want to, thanks to kallsyms_lookup_name(). But yeah, we should at least keep some obstacles in place. This needs more thought and discussion. > So I still think it is not a good idea because of EXPORT_SYMBOL and > because of delayed module loading. Do you have the implementation already > (even if not complete) somewhere? What are exactly the problems with s390x > relocation types (I still haven't looked into them :/)? Jessica can better answer this question, but it has to do with the fact that s390 relies on PLT/GOT tables. Technically I don't think it's an insurmountable obstacle. It might be fixable be changing the klp_write_module_reloc() interface and adding more intelligence to kpatch-build. But it's a little crazy to keep bending over backwards to add support for architectures, when all the code we need for every arch is already in the kernel module loader today. -- Josh -- 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
