race in getrusage()

From: Henry Cejtin (henry@sourcelight.com)
Date: Tue Jul 17 2001 - 00:35:35 EST

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 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/

This archive was generated by hypermail 2b29 : Mon Jul 23 2001 - 21:00:08 EST