On Thu, Nov 13, 2014 at 06:02:45PM +0100, Vojtech Pavlik wrote:
> Hi all,
>
> I'be trying to drill down on what is the minimum consistency model that
> still allows function prototype changes: Adding, removing or modifying
> arguments of a function or changing its return type.
>
> Because I believe this is the most important functionality that the null
> model, where functions are simply replaced immediately using ftrace is
> lacking.
>
> Under my proposed classification, LEAVE_PATCHED_SET + SWITCH_THREAD
> offers this.
>
> But even that is fairly complex and would require large parts of kpatch,
> kGraft and Masami's code.
>
> The really trivial solution is:
>
>
> static void lpc_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> struct ftrace_ops *ops, struct pt_regs *regs)
> {
> struct lpc_func *func = ops->private;
>
> if (!within_patched_set(parent_ip))
> regs->ip = func->new_addr;
> }
>
>
> Obviously, within_patched_set() would need an efficient data structure,
> like an interval tree, to quickly decide whether the parent ip address
> is within the patched set.
>
> This is enough to make sure that function calls are consistent.
>
> No stack checking, no stop_machine(), no forcing threads through
> userspace.
>
> A disadvantage is that it doesn't give an indication when patching is
> over and the trampoline can be removed. For that, I currently don't see
> a better method than tracking kernel exits and/or stack analysis.
>
> What do you think?
Interesting idea. But the hard part is figuring out when the patching
is complete. Once you implement that, it might not be so minimal.
BTW, here's a very simple way to implement LEAVE_PATCHED_SET +
SWITCH_THREAD:
for each thread {
if (!on_cpu(thread) and !on_stack(thread, funcs) {
switch thread to new universe
} else if (unfreezable kthread) {
retry and/or fail (kthread is either CPU-bound or is using patched func)
} else {
freeze thread
if (!on_stack(thread, funcs))
switch thread to new universe
else
fail (patch affects freezer/schedule path)
}
}
Note this approach will fail in a few cases, like if you have a
CPU-bound kthread (but we can keep retrying in that case), if a patched
function is in use by a sleeping kthread, or if the patch affects the
freeze/schedule path.
But the code is simple and converges to the patched state quickly.
Thoughts?
--
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
