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

[Jiri Kosina]

[ 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
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/