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. > 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. 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. > 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. > > One way to do it would be by brute-force: straight after "execve" > unmap the tracee's vdso page, Not sure this will be always possible. For example, my (old) glibc assumes that vsyscall() must work, I won't be surprised if some time later it won't work without vdso. But again, I do not know. > then manipulate the ELF tables in > its memory so the VDSO entry is gone and the library will not go > looking for it. Probably it would be enough to simply erase AT_SYSINFO_EHDR note, but again, I can be easily wrong. > I just wonder whether you know of an easier and more standard way > to disable the vdso in user-mode Only the kernel parameter, afaics. vdso=0 > - ideally on a per-process basis, > or otherwise, if it's too hard, on the whole computer. I searched > the web and found references to "/proc/sys/vm/vdso_enable", but I > have no such file or "sysctl" option on my system. sys/vm/vdso_enabled, but only if CONFIG_X86_32 for some reason. See kernel/sysctl.c Oleg. -- 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/
