On Thu, Jan 30, 2014 at 7:52 AM, Stefani Seibold <stef...@seibold.net> wrote: > Am Donnerstag, den 30.01.2014, 07:31 -0800 schrieb H. Peter Anvin: >> On 01/30/2014 02:49 AM, stef...@seibold.net wrote: >> > The VDSO page for a 32 bit resided now on 0xffffc000, followed by the VVAR >> > and >> > HPET page. >> >> Any reason to not move the vdso base page to the top, in order to avoid >> breaking broken applications? It seems a fairly innocuous shuffle... >> probably little gain, but very little cost. >> >> -hpa >> > > The reason is that i get need than an additional VMA for HPET and VVAR. > > I seen no break of applications since the __FIXADDR_TOP is not on a fix > place. Lguest, XEN, OPLC and the reservetop Kernel Parameter will change > the VDSO Page Address.
By definition there aren't any broken users of the new functions, because there aren't any users at all. So... should we start randomizing this thing from the beginning? Also, since the VVAR page has a real vma, should something be done to prevent mprotect or ptrace from COWing it? Users will be rather surprised if it suddenly stops updating. Finally, this might be the time to kill off the userspace mapping of the HPET. I suspect that there are few if any machines for which the HPET is fast enough that avoiding a syscall matters at all. (On my box at work, reading the HPET takes ~500 nanoseconds. I can do a lot of syscalls in that amount of time.) > > - Stefani > -- Andy Lutomirski AMA Capital Management, LLC -- 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/