All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.