Bug 14438 - clock_gettime CLOCK_THREAD_CPUTIME_ID doesn't delegate to vsyscall
Summary: clock_gettime CLOCK_THREAD_CPUTIME_ID doesn't delegate to vsyscall
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.17
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-06 19:03 UTC by Arun Sharma
Modified: 2014-06-17 18:47 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-

Attachments
clock_gettime() makes syscalls, but __vdso_clock_gettime doesn't. (356 bytes, application/octet-stream)
2012-08-06 19:03 UTC, Arun Sharma 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Arun Sharma 2012-08-06 19:03:06 UTC 
Created attachment 6566 [details]
clock_gettime() makes syscalls, but __vdso_clock_gettime doesn't.

clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts) seems to always make a syscall, even on kernels that provide a vdso. Although upstream kernels don't have the patches we're running with, I find this behavior surprising.

Why doesn't glibc always call __vdso_clock_gettime() and let the kernel decide on the best implementation regardless of the clock id?

Relevant patches:

http://thread.gmane.org/gmane.linux.kernel/1231015/focus=1231016
Comment 1 Siddhesh Poyarekar 2013-05-10 13:02:28 UTC 
clock_gettime always calls __vdso_clock_gettime on x86_64.  What are you testing on?
Comment 2 Arun Sharma 2013-05-10 14:09:18 UTC 
3.2 kernel plus out of tree patches which provide a vdso implementation for
this clock.
On May 10, 2013 6:02 AM, "siddhesh at redhat dot com" <
sourceware-bugzilla@sourceware.org> wrote:

> http://sourceware.org/bugzilla/show_bug.cgi?id=14438
>
> Siddhesh Poyarekar <siddhesh at redhat dot com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |siddhesh at redhat dot com
>
> --- Comment #1 from Siddhesh Poyarekar <siddhesh at redhat dot com>
> 2013-05-10 13:02:28 UTC ---
> clock_gettime always calls __vdso_clock_gettime on x86_64.  What are you
> testing on?
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>
Comment 3 Siddhesh Poyarekar 2013-05-16 06:48:47 UTC 
(In reply to comment #2)
> 3.2 kernel plus out of tree patches which provide a vdso implementation for
> this clock.

x86_64 or something else?  x86_64 calls __vdso_clock_gettime.
Comment 4 Arun Sharma 2013-07-26 18:37:45 UTC 
x86_64. IIRC: the implementation calls vdso for some clockids, but not others.
Comment 5 Siddhesh Poyarekar 2013-07-27 02:45:18 UTC 
It calls vdso_clock_gettime for all clockids.  If vdso function has support for some clockids but not others, for which it does a context switch into the kernel.

sysdeps/unix/clock_gettime.c:
...
    default:
#ifdef SYSDEP_GETTIME_CPU
      SYSDEP_GETTIME_CPU (clock_id, tp);
#endif
...

sysdeps/unix/sysv/linux/clock_gettime.c
...
#define SYSDEP_GETTIME_CPU(clock_id, tp) \
  retval = SYSCALL_GETTIME (clock_id, tp); \
  break
...

sysdeps/unix/sysv/linux/x86_64/clock_gettime.c
...
# define SYSCALL_GETTIME(id, tp) \
  ({ long int (*f) (clockid_t, struct timespec *) = __vdso_clock_gettime; \
  long int v_ret;                                                         \
  PTR_DEMANGLE (f);                                                       \
  v_ret = f (id, tp);                                                     \
  if (INTERNAL_SYSCALL_ERROR_P (v_ret, )) {                               \
    __set_errno (INTERNAL_SYSCALL_ERRNO (v_ret, ));                       \
    v_ret = -1;                                                           \
  }                                                                       \
  v_ret; })
...
Comment 6 Arun Sharma 2013-10-04 15:53:22 UTC 
Verified in glibc-2.14. Thanks for looking into this!