Jeremy Fitzhardinge <jeremy@xxxxxxxx> writes: > Ingo Molnar wrote: >> that's what is the case right now, but much of the intention behind the >> vma based vDSO is to enable per-process randomized vdso locations, and >> various distributions do that. So the 'modern' vDSO concept is very much >> relocatable. > > No, the point is that it never needs relocating. The kernel can map it > anywhere and userspace can cope. Its only the broken glibcs which > require relocation. Ok. So to summarize. There are three ways of finding the VDSO. - AT_SYSINFO - AT_SYSINFO_EHDR - known fixed address (see x86_64) Currently it doesn't sound like you need to deal with the known fixed address case but COMPAT_VDSO also provides that. If userspace uses AT_SYSINFO the premise is that it is not expecting not to need to perform any relocation processing. If userspace uses AT_SYSINFO_EHDR it expects it needs to perform relocation processing and fixes up whatever needs fixing up. With the module code we have shown the kernel is capable of performing relocation processing at times and it works. So is it possible to simply relocate the normal vdso and fixup it's program header so it shows that relocation is not necessary. If you can do that and still export AT_SYSINFO so the problem user space still runs you are good. (If you can relocate the vdso you should be able to relocate it anywhere). Otherwise it probably just make sense to simply not export a VDSO on those systems. This would leave COMPAT_VDSO for the case where you must use one magic fixed address, and if user space does not require that it means COMPAT_VDSO could be completely removed. Eric _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
