On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
So I think this doesn't fix the problem. Dynamic relocations are
applied to the "patch module", whereas the above code deals with the
initialization order of the "patched module". This distinction
originally confused me as well, until Jessica set me straight.
Let me try to illustrate the problem with an example. Imagine you have
a patch module P which applies a patch to module M. P replaces M's
function F with a new function F', which uses paravirt ops.
1) Patch P is loaded before module M. P's new function F' has an
instruction which is patched by apply_paravirt(), even though the
patch hasn't been applied yet.
2) Module M is loaded. Before applying the patch, livepatch tries to
apply a klp_reloc to the instruction in F' which was already patched
by apply_paravirt() in step 1. This results in undefined behavior
because it tries to patch the original instruction but instead
patches the new paravirt instruction.
So the above patch makes no difference because the paravirt module
loading order doesn't really matter.
Hi,
we are trying really hard to understand the actual culprit here and as it
is quite confusing I have several questions/comments...
1. can you provide dynrela sections of the patch module from
https://github.com/dynup/kpatch/issues/580? What is interesting is that
kvm_arch_vm_ioctl() function contains rela records only for trivial (==
exported) symbols from the first look. The problem should be there only if
you want to patch a function which reference some paravirt_ops unexported
symbol. For that symbol dynrela should be created.