.smp_locks incompatibility

[flaming-toast]

Although we regenerate and include .smp_locks in patch modules, this isn't sufficient enough for the module loader to correctly patch smp lock alternatives.

If we look at arch/x86/kernel/module.c, in module_finalize(), the module loader will only look for a single .text section to pass to alternatives_smp_module_add(). Thus if alternatives_smp_{lock,unlock}() get called, only the patch module's .text section is scanned for LOCK prefixes when going from SMP->UP (or DS segment override prefixes if patching from UP->SMP). The problem is that patch modules have multiple .text sections due to -ffunction-sections.

To give a concrete example, say a patch module has .text and .text.kvm_arch_vcpu_ioctl_set_sregs. Say this patch module also has an .smp_locks entry that points to an offset within .text.kvm_arch_vcpu_ioctl_set_sregs. The module loader will only scan and patch any addresses within the patch module's .text section, and not .text.kvm_arch_vcpu_ioctl_set_sregs.

I don't think this is kpatch's problem though, since I think the module loader's behavior could possibly be changed to account for smp_lock entries that point to different text sections...For now the problem isn't severe, we're just missing out on a few smp/up-related optimizations is all.

[zhouchengming1]

I think if we can let the create-diff-object produce a object that more like a normal object, like has just one .text section ? And as we don't use -ffunction-sections flag when we at last build the patch module, so we will have a patch module that just has one .text section, more like a normal module. So how do you think?

[github-actions[bot]]

This issue has been open for 30 days with no activity and no assignee. It will be closed in 7 days unless a comment is added.

[github-actions[bot]]

This issue was closed because it was inactive for 7 days after being marked stale.