Bug 11972

Summary: CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID not setabble
Product: Timers Reporter: Michael Kerrisk (mtk.manpages)
Component: OtherAssignee: john stultz (john.stultz)
Status: CLOSED INVALID    
Severity: normal CC: a.p.zijlstra, tglx
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: any Subsystem:
Regression: No Bisected commit-id:

Description Michael Kerrisk 2008-11-07 09:30:03 UTC
Latest working kernel version: none
Earliest failing kernel version: all
Distribution: SUSE 11.0
Hardware Environment: x86-32
Software Environment:

Problem Description:
According to POSIX.1-2001, the CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID should be setabble via clock_gettime().  Instead Linux fails clock_time() with EINVAL for these timers.

Steps to reproduce:

Use the program below.

#define _GNU_SOURCE
#include <time.h>
#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <errno.h>

#define errMsg(msg)             { perror(msg); }

int
main(int argc, char *argv[])
{
    struct timespec ts;

    ts.tv_sec = 0;
    ts.tv_nsec = 0;

    if (syscall(SYS_clock_settime, CLOCK_PROCESS_CPUTIME_ID, &ts) == -1)
        errMsg("clock_settime-CLOCK_PROCESS_CPUTIME_ID");
    if (syscall(SYS_clock_settime, CLOCK_THREAD_CPUTIME_ID, &ts) == -1)
        errMsg("clock_settime-CLOCK_THREAD_CPUTIME_ID");

    exit(EXIT_SUCCESS);
}
Comment 1 john stultz 2009-06-10 19:18:31 UTC
Huh. This seems odd. Those are process accounting values, and I'm not sure I see the rational for user-land being able to change them.

Is there any pointer to the portion of the spec in question, or maybe a link to discussion around why this would be desired?
Comment 2 john stultz 2010-01-05 01:00:48 UTC
Michael: Could you provide more rational for why the process accounting values should be settable?
Comment 3 Michael Kerrisk 2010-01-05 15:48:47 UTC
Hi John,

See http://www.opengroup.org/onlinepubs/009695399/functions/clock_getres.html

I don't know exactly what the rationale is, but the standard seems pretty clear that these clocks should be settable.
Comment 4 john stultz 2010-01-14 00:30:08 UTC
Thomas, Peter: What's your thought on this? Is this just posix being crazy?

Or should we add an extra layer of indirection (basically providing a settable per thread offset that would be added to the thread cpu time before returning) in order to make this work?

thanks
-john
Comment 5 Anonymous Emailer 2010-01-14 08:37:17 UTC
Reply-To: peterz@infradead.org

On Thu, 2010-01-14 at 00:30 +0000, bugzilla-daemon@bugzilla.kernel.org
wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=11972
> 
> 
> john stultz <johnstul@us.ibm.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |a.p.zijlstra@chello.nl,
>                    |                            |tglx@linutronix.de
> 
> 
> 
> 
> --- Comment #4 from john stultz <johnstul@us.ibm.com>  2010-01-14 00:30:08
> ---
> Thomas, Peter: What's your thought on this? Is this just posix being crazy?
> 
> Or should we add an extra layer of indirection (basically providing a
> settable
> per thread offset that would be added to the thread cpu time before
> returning)
> in order to make this work?

Sounds daft, if people want per thread offsets they can do so in
userspace, right?
Comment 6 Michael Kerrisk 2010-02-03 04:11:46 UTC
Take a look at http://thread.gmane.org/gmane.comp.standards.posix.austin.general/1671.

Don Cragun noted:

[[
The third from the last paragraph of the DESCRIPTION section of
clock_getres(),  clock_gettime(), and clock_settime() on XSH7, P668,
L22645 says:
    "Appropriate privileges to set a particular clock are
     implementation-defined."
If the Linux kernel documents that no process has the privileges
required to set the clocks identified by CLOCK_PROCESS_CPUTIME_ID and
CLOCK_THREAD_CPUTIME_ID, it meets the standard's requirements for
this issue.
]]

So, at the moment, it sounds to me like Linux doesn't need to implement this to be standards conformant.
Comment 7 john stultz 2010-04-05 21:58:31 UTC
I'm closing this bug out as invalid.