[ 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 live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
