[lkml]   [2001]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectrace in getrusage()
Sorry for sending this bug report out to this broad an audience, but there is
an old bug in getrusage() (it has been there since at least 2.2.5 and
probably way before that and is still in 2.4.6). Depending on the cleverness
of the C compiler, when you do
getrusage(RUSAGE_SELF, &rbuf)
you can get one of the following:

A rbuf.ru_stime which is 1 second too small. (In particular, 1 second
smaller than you got from a previous call in the same process.)
rbuf.ru_stime.tv_usec = 10^6 (i.e., larger than should be possible).

The bug is caused by the fact that in kernel/sys.c, in the getrusage()
function, the p->times.tms_stime might change while the code is running.
Since it isn't marked as being volatile, if the compiler optimizes the code
by subtracting the r.ru_stime.tv_sec * HZ from a second load of
p->times.tms_stime then you get the r.ru_stime.tv_usec set to 10^6. If it
reloads p->times.tms_stime then you get the lost second. I have seen both
behaviors, depending on the compiler being used. In particular, the kernel
distributed with Red Hat 7.1 shows the lost second phenomenon, and the 10^6
value for ru_stime.tv_usec on Red Hat 6.0's kernel.

The fix is to just load p->times.tms_stime into a local variable and then use
the local copy for setting both the tv_sec and tv_usec fields of r.ru_stime.

Only r.ru_stime is vulnerable since the process is in a system call at the

Note, to force the compiler to actually fetch p->times.tms_stime, and to
fetch it only once, requires something like this:
clock_t tmp;

tmp = *(volatile clock_t *)&p->times.tms_stime;
r.ru_utime.tv_sec = CT_TO_SECS(tmp);
r.ru_utime.tv_usec = CT_TO_USECS(tmp);
otherwise the compiler is quite free to ignore the load and to simply fetch
p->times.tms_stime twice.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:57    [W:0.029 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site