On Tue, Aug 8, 2017 at 11:58 AM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
>
> Take for example the lock_is_held_type() function. In vmlinux, it has
> the following instruction:
>
> callq *0xffffffff85a94880 (pv_irq_ops.save_fl)
>
> At runtime, that instruction is patched and replaced with a fast inline
> version of arch_local_save_flags() which eliminates the call:
>
> pushfq
> pop %rax
>
> The problem is when an interrupt hits after the push:
>
> pushfq
> --- irq ---
> pop %rax
That should actually be something easily fixable, for an odd reason:
the instruction boundaries are different.
> I'm not sure what the solution should be. It will probably need to be
> one of the following:
>
> a) either don't allow runtime "alternative" patches to mess with the
> stack pointer (objtool could enforce this); or
>
> b) come up with some way to register such patches with the ORC
> unwinder at runtime.
c) just add ORC data for the alternative statically and _unconditionally_.
No runtime registration. Just an unconditional entry for the
particular IP that comes after the "pushfq". It cannot match the
"callq" instruction, since it would be in the middle of that
instruction.
Basically, just do a "union" of the ORC data for all the alternatives.
Now, objtool should still verify that the instruction pointers for
alternatives are unique - or that they share the same ORC unwinder
information if they are not.
But in cases like this, when the instruction boundaires are different,
things should "just work", with no need for any special cases.
Hmm?
Linus
--
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
