From: Jan Wagner <jwagner@kurp.hut.fi>
To: linux-kernel@vger.kernel.org
Subject: 32-bit sys/times.h incorrect return value (fwd)
Date: Thu, 13 Aug 2009 18:32:11 +0300 (EEST) [thread overview]
Message-ID: <alpine.DEB.2.00.0908131831580.28962@orbit.lan> (raw)
Hi,
we see times() return a really large positive value like 0x66693CF1 i.e.
signed int32 +1718172913 just a few minutes after booting.
Note that clock_gettime(CLOCK_MONOTONIC) works correctly and returns the
uptime. While times() +1718172913/100Hz time is in no relation to uptime.
Checking 'man 2 times': "Since Linux 2.6, this point is (2^32/HZ) - 300 (i.e.,
about 429 million) seconds before system boot time. [...] the returned value
may overflow the range of clock_t [...]"
Hence in theory on a 32-bit platform where clock_t is signed 32-bit, at first
times() should return negative values.
Then 300 seconds later they should become positive. Correct?
This should also happen via glibc times() call. There the times()
./sysdeps/unix/sysv/linux/times.c
simply does
clock_t ret = INTERNAL_SYSCALL (times, err, 1, buf);
with no extra "+- some constant".
In the kernel all jiffies and times syscall related handling is 64-bit:
---------
amn@multics:/home/etu/Desktop/linux-2.6.30.3/include$ fgrep INITIAL_JIFFIES
linux/jiffies.h:#define INITIAL_JIFFIES ((unsigned long)(unsigned int)
(-300*HZ))
kernel/sys.c: return (long) jiffies_64_to_clock_t(get_jiffies_64());
kernel/time.c:u64 get_jiffies_64(void)
kernel/time.c: ret = jiffies_64;
---------
On 32-bit platforms and signed int32 clock_t it should take at least
octave:1> 2^31/(24*60*60 * 100)
ans = 248.55
octave:2> (2^31/100 - 300)/(24*60*60)
ans = 248.55
days until the positive times() return value wraps back to smallest negative
signed 32-bit int.
However, two bugs(?) :
1) times() return value after 1080 'uptime' seconds is 0x66693CF1, why?
Expected value would be (1080-300)*100Hz = 78000 = 0x000130B0 !
2) the times() wraps to negative only after 50 days uptime. Following the
intention of INITIAL_JIFFIES, how is this 50-day warp supposed to reveal
wrapping bugs right at 300 seconds after boot?
2) on 64-bit platforms, clock_t is 64-bit. There times() does not wrap after 50
days, however it still starts at 0x000000006669**** !?
Any ideas?
- Jan
next reply other threads:[~2009-08-13 15:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-13 15:32 Jan Wagner [this message]
2009-08-14 8:36 ` 32-bit sys/times.h incorrect return value (fwd) Jens Rosenboom
2009-08-14 8:59 ` Jens Rosenboom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.0908131831580.28962@orbit.lan \
--to=jwagner@kurp.hut.fi \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.