On 11/22/2012 08:12 PM, Oleg Nesterov wrote: > On 11/22, Amnon Shiloh wrote: >> >> Now however, that "vsyscall" was effectively replaced by vdso, it >> creates a new problem for me and probably for anyone else who uses >> some form of checkpoint/restore: > > Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they > seem to enjoy trying to solve the c/r problems.
Thank you :) >> Suppose a process is checkpointed because the system needs to reboot >> for a kernel-upgrade, then restored on the new and different kernel. >> The new VDSO page may no longer match the new kernel - it could for >> example fetch data from addresses in the vsyscall page that now >> contain different things; or in case the hardware also was changed, >> it may use machine-instructions that are now illegal. If we could make VDSO entry points not move across the kernels (iow, make them looks as yet another syscall table) this would help, I suppose. > Sure. You shouldn't try to save/restore this page(s) directly. But > I do not really understand why do you need. IOW, I don't really > understand the problem, it depends on what c/r actually does. Think about it like this -- you stop a process, then change the kern^w VDSO page. Everything should work as it used to be :) >> As I don't mind to forego the "fast" sys_time(), my obvious solution >> is to disable the vdso for traced processes that may be checkpointed. This is very poor solution from my POV. Nobody wants to have their applications work fast only until it's checkpointed. Thanks, Pavel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
