public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/12813] New: Linux x86_64: glibc should prefer the vDSO over vsyscalls
@ 2011-05-26 21:25 luto at mit dot edu
  2011-05-27 15:05 ` [Bug libc/12813] " luto at mit dot edu
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: luto at mit dot edu @ 2011-05-26 21:25 UTC (permalink / raw)
  To: glibc-bugs

http://sourceware.org/bugzilla/show_bug.cgi?id=12813

           Summary: Linux x86_64: glibc should prefer the vDSO over
                    vsyscalls
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: luto@mit.edu


As of right now, all functionality in the vsyscall page is available through
the vDSO on x86_64.  The missing function was time(), but that landed here:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f144a6b4d1688675d88990e29567b2335b48205e

and is faster than the vsyscall version because of

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=973aa8181e10050809b56ecbaadd01495766a19e

Currently (AFAICT), glibc will use the gettimeofday vsyscall in static builds
due to:

#ifdef SHARED
        movq    __vdso_gettimeofday(%rip), %rax
        PTR_DEMANGLE (%rax)
#else
        movq    $VSYSCALL_ADDR_vgettimeofday, %rax
#endif

and will unconditionally use the vsyscall versions of time and getcpu.


It would be nice to kill off the vsyscall page entirely and replace it with
some kind of emulation layer that keeps old code working (with a performance
penalty) but doesn't leave a syscall instruction sitting at a fixed address.

Before doing that, glibc should stop using it in new code, at least on kernels
that have a vDSO.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libc/12813] Linux x86_64: glibc should prefer the vDSO over vsyscalls
  2011-05-26 21:25 [Bug libc/12813] New: Linux x86_64: glibc should prefer the vDSO over vsyscalls luto at mit dot edu
@ 2011-05-27 15:05 ` luto at mit dot edu
  2011-05-28 12:14 ` drepper.fsp at gmail dot com
  2014-06-27 13:15 ` fweimer at redhat dot com
  2 siblings, 0 replies; 4+ messages in thread
From: luto at mit dot edu @ 2011-05-27 15:05 UTC (permalink / raw)
  To: glibc-bugs

http://sourceware.org/bugzilla/show_bug.cgi?id=12813

--- Comment #1 from Andy Lutomirski <luto at mit dot edu> 2011-05-27 15:04:46 UTC ---
As an added benefit of the vDSO over vsyscalls: things like UML can replace the
vDSO if they want to.  This means that sched_getcpu and gettimeofday would have
a better chance of returning the guest's answer (instead of the host's) on UML.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libc/12813] Linux x86_64: glibc should prefer the vDSO over vsyscalls
  2011-05-26 21:25 [Bug libc/12813] New: Linux x86_64: glibc should prefer the vDSO over vsyscalls luto at mit dot edu
  2011-05-27 15:05 ` [Bug libc/12813] " luto at mit dot edu
@ 2011-05-28 12:14 ` drepper.fsp at gmail dot com
  2014-06-27 13:15 ` fweimer at redhat dot com
  2 siblings, 0 replies; 4+ messages in thread
From: drepper.fsp at gmail dot com @ 2011-05-28 12:14 UTC (permalink / raw)
  To: glibc-bugs

http://sourceware.org/bugzilla/show_bug.cgi?id=12813

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Ulrich Drepper <drepper.fsp at gmail dot com> 2011-05-28 12:13:32 UTC ---
I did add code to use the vdso in dynamically linked code.  But I don't change
the static code.  Just go ahead, make the vsyscalls slow.  Noone should use
statically linked code at all.  It's OK to be slower.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libc/12813] Linux x86_64: glibc should prefer the vDSO over vsyscalls
  2011-05-26 21:25 [Bug libc/12813] New: Linux x86_64: glibc should prefer the vDSO over vsyscalls luto at mit dot edu
  2011-05-27 15:05 ` [Bug libc/12813] " luto at mit dot edu
  2011-05-28 12:14 ` drepper.fsp at gmail dot com
@ 2014-06-27 13:15 ` fweimer at redhat dot com
  2 siblings, 0 replies; 4+ messages in thread
From: fweimer at redhat dot com @ 2014-06-27 13:15 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=12813

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-06-27 13:15 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-26 21:25 [Bug libc/12813] New: Linux x86_64: glibc should prefer the vDSO over vsyscalls luto at mit dot edu
2011-05-27 15:05 ` [Bug libc/12813] " luto at mit dot edu
2011-05-28 12:14 ` drepper.fsp at gmail dot com
2014-06-27 13:15 ` fweimer at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).