Re: compat_sys_times() bogus until jiffies >= 0.

From: Michael Kerrisk
Date: Thu Dec 20 2007 - 06:37:18 EST


David, Andrew, Paul,

A late coda to this thread, but I'll just note some changes I'm making to
the man page (which I'd like you to review -- please see below), and note a
few other points.

Andrew, you asked about what happens for x86 with the -1 to -4095 return
for other syscalls. At least two other syscalls suffer the same problem.
>From the fcntl(2) man page:

BUGS
A limitation of the Linux system call conventions on some
architectures (notably x86) means that if a (negative)
process group ID to be returned by F_GETOWN falls in the
range -1 to -4095, then the return value is wrongly
interpreted by glibc as an error in the system call; that
is, the return value of fcntl() will be -1, and errno
will contain the (positive) process group ID.

Some testing just now shows me that lseek() on /dev/mem suffers similar
problems when seeking to bytes 0xfffff001 through to 0xffffffff.

Ulrich Drepper wrote:
> Chris Friesen wrote:
>>> A possible remedy is to return the ticks since process start time, which
>>> delays the wrap around much further. POSIX only demands consistency
>>> within the same process.
>> This would be an interesting solution.
>
>> The man page for linux states that the return code is time since system
>> boot, so that could realistically be expected to correlate between
>> different processes.
>
> The Linux man page is documenting existing functionality on top of what
> the standard requires. Programmers should ever only require what the
> standard guarantees.
>
> I am perfectly willing to support a solution where the time is measured
>>from process startup time. The only code using times() I found is
> cross-platform and most likely does not depend on the value returned is
> usable in isolation (only in a difference).

Did I miss anything? Is anyone actually working on a solution along these
lines?

In the meantime, for man-pages-2.74, I've reworked the description of the
return value:

RETURN VALUE
times() returns the number of clock ticks that have
elapsed since an arbitrary point in the past. The return
value may overflow the possible range of type clock_t.
On error, (clock_t) -1 is returned, and errno is set
appropriately.

I moved the Linux specific details of the return value to NOTES, and added
a warning about relying on those details:

NOTES
...

On Linux, the "arbitrary point in the past" from which
the return value of times() is measured has varied across
kernel versions. On Linux 2.4 and earlier this point is
the moment the system was booted. Since Linux 2.6, this
point is (2^32/HZ) - 300 (i.e., about 429 million) sec-
onds before system boot time. This variability across
kernel versions (and across Unix implementations), com-
bined with the fact that the returned value may overflow
the range of clock_t, means that a portable application
would be wise to avoid using this value. To measure
changes in elapsed time, use gettimeofday(2) instead.

Under BUGS I added:

BUGS
A limitation of the Linux system call conventions on some
architectures (notably x86) means that on Linux 2.6 there
is a small time window (41 seconds) soon after boot when
times(2) can return -1, falsely indicating that an error
occurred. The same problem can occur when the return
value wraps passed the maximum value that can be stored
in clockid_t.

Look okay to you folks?

Cheers,

Michael
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug? Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/