Re: live patching design (was: Re: [PATCH 1/3] sched: add sched_task_call())

From: Jiri Kosina
Date: Sun Feb 22 2015 - 14:18:17 EST

[ live-patching@ ML added to CC here as well ]

On Sun, 22 Feb 2015, Ingo Molnar wrote:

> > BTW how exactly do you envision this will work? Do I understand your
> > proposal correctly that EINTR will be "handled" somewhere in the "live
> > patching special signal handler" and then have the interrupted syscall
> > restarted?
> If you want to think about it in signal handling terms then it's a new
> automatic in-kernel handler, which does not actually return back to
> user-mode at all.
> We can do it via the signals machinery (mainly to reuse all the existing
> signal_pending() code in various syscalls), or via new TIF flags like
> the user work machinery: the principle is the same: interrupt out of
> syscall functions into a central place and restart them, and return to
> user-space later on as if a single call had been performed.
> This necessarily means some changes to syscalls, but not insurmountable
> ones - and checkpoint/restore support would want to have similar changes
> in any case so we can hit two birds with the same stone.

Understood. I think this by itself really would be a huge improvement on
how to force tasks to converge to the new universe without confusing the
userspace via artificial signals (i.e. even with the lazy migration
aproaches, without full serialization checkpoint). As I said yesterday, I
am pretty sure we'll experiment with this in kgraft. Thanks for bringing
this idea up,

Jiri Kosina
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at