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

[Michael Kerrisk <mtk.manpages@googlemail.com>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/