Messages in this thread | | | From | Andrew Lutomirski <> | Date | Sun, 29 May 2011 10:57:51 -0400 | Subject | Re: [GIT pull] x86 vdso updates |
| |
On Sun, May 29, 2011 at 5:51 AM, richard -rw- weinberger <richard.weinberger@gmail.com> wrote: > On Fri, May 27, 2011 at 5:05 PM, Andrew Lutomirski <luto@mit.edu> wrote: >> On Fri, May 27, 2011 at 10:59 AM, richard -rw- weinberger >> <richard.weinberger@gmail.com> wrote: >>> On Fri, May 27, 2011 at 2:10 PM, Andrew Lutomirski <luto@mit.edu> wrote: >>>> On Fri, May 27, 2011 at 7:59 AM, richard -rw- weinberger >>>> If this is considered enough of a regression, then I guess we can >>>> leave vsyscall64 around for awhile, but it will require extra work in >>>> the soon-to-be syscall emulation hack to make sure that UML can still >>>> trap the syscall. >>> >>> As long the time within UML is synchronous with the host everything is >>> fine, right? >> >> I think so. I haven't used UML in a long time. >> >>> So, as _last_ choice we could disable the ability to change the time within UML. >>> >>> IMHO it's not a big deal when getcpu() returns a wrong CPU layout on UML. >>> >>>> The real solution is to fix glibc to use the vDSO which should avoid >>>> this problem entirely. >>> > > Yesterday I had a closer look at 64bit UML. > Glibc is always using vsyscalls because 64bit UML does not support the vDSO. > > On 32bit UML simply scans the ELF auxiliary vector provided by the host to > get the address of the vDSO. > How can I get this address on a 64bit host?
I believe it's exactly the same. There's an auxv entry that points to the vDSO.
--Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |