From: Andrew Morton <akpm@linux-foundation.org>
To: lkml@davidb.org, linux-kernel@vger.kernel.org,
drepper@redhat.com, mtk-manpages@gmx.net
Subject: Re: compat_sys_times() bogus until jiffies >= 0.
Date: Wed, 7 Nov 2007 16:18:53 -0800 [thread overview]
Message-ID: <20071107161853.044b6e8f.akpm@linux-foundation.org> (raw)
In-Reply-To: <20071107152833.6f302c2a.akpm@linux-foundation.org>
> On Wed, 7 Nov 2007 15:28:33 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Wed, 7 Nov 2007 14:47:22 -0800 David Brown <lkml@davidb.org> wrote:
> > compat_sys_times() has bogus return until jiffies is >= 0. I discovered
> > this running LTP within 5 minutes of booting.
> >
> > The return result
> >
> > return compat_jiffies_to_clock_t(jiffies);
> >
> > will return '-1' to user space and set the negated clock_t value to errno.
> >
> > I'm not sure what the correct fix for this is. I can come up with a patch
> > if anyone has ideas on how to fix it.
> >
> > At minimum, perhaps it should return a sane errno value.
>
> RETURN VALUE
> times() returns the number of clock ticks that have elapsed since an
> arbitrary point in the past. For 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) seconds before system boot
> time. The return value may overflow the possible range of type
> clock_t. On error, (clock_t) -1 is returned, and errno is set appro-
> priately.
>
>
> Perhaps this is a bug in glibc: it is interpreting the times() return value
> in the same way as other syscalls.
>
> It would have been sensible for us to add INITIAL_JIFFIES to the value
> instead of exposing this kernel-only detail to the world, although the
> problem will of course reoccur once jiffies hits 0x80000000. Unfortunately
> we've even gone and enshrined this bogon in the manpage.
>
> Proposed fix:
>
> - return compat_jiffies_to_clock_t(jiffies);
> + return compat_jiffies_to_clock_t((jiffies + INITIAL_JIFFIES) &
> + 0x7fffffff);
>
> ?
Like this?
It gets messy.
From: Andrew Morton <akpm@linux-foundation.org>
David Brown points out that compat_sys_times() (and sys_times()) can return
arbitrary 32-bit (or 64-bit values). If these happen to be negative (jiffy
wrap, or before INITIAL_JIFFIES) then libc will interpret this as an error and
will return -1 to the libc user and will set errno.
The manpage for times(2) says:
times() returns the number of clock ticks that have elapsed since an
arbitrary point in the past. For 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) seconds before system boot
time. The return value may overflow the possible range of type
clock_t. On error, (clock_t) -1 is returned, and errno is set appro-
priately.
We can fix this by masking the return value down to a 31-bit (63-bit) value.
Also, let's correct for INTIAL_JIFFIES - this isn't a detail which should be
exposed to userspace.
Unfortunately this change can break userspace. If a program was (correctly)
doing:
unsigned long start = times(...);
...
unsigned long end = times(...);
unsigned long delta = end - start;
then `delta' can be grossly wrong if we wrapped in the interval. Instead
userspace will need to mask `delta' by 0x7fffffff (0x7fffffffffffffff) to get
the correct number.
But userspace was already busted in the presence of wraparound, due to glibc's
convert-to-negative-one behaviour.
Given all this stuff, the return value from sys_times() doesn't seem a
particularly useful or reliable kernel interface.
Cc: David Brown <lkml@davidb.org>
Cc: Ulrich Drepper <drepper@redhat.com>
Cc: Michael Kerrisk <mtk-manpages@gmx.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/compat.c | 3 ++-
kernel/sys.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff -puN kernel/sys.c~a kernel/sys.c
--- a/kernel/sys.c~a
+++ a/kernel/sys.c
@@ -897,7 +897,8 @@ asmlinkage long sys_times(struct tms __u
if (copy_to_user(tbuf, &tmp, sizeof(struct tms)))
return -EFAULT;
}
- return (long) jiffies_64_to_clock_t(get_jiffies_64());
+ return jiffies_64_to_clock_t((get_jiffies_64() + INITIAL_JIFFIES) &
+ LONG_MAX);
}
/*
diff -puN kernel/compat.c~a kernel/compat.c
--- a/kernel/compat.c~a
+++ a/kernel/compat.c
@@ -162,7 +162,8 @@ asmlinkage long compat_sys_times(struct
if (copy_to_user(tbuf, &tmp, sizeof(tmp)))
return -EFAULT;
}
- return compat_jiffies_to_clock_t(jiffies);
+ return compat_jiffies_to_clock_t((jiffies + INITIAL_JIFFIES) &
+ LONG_MAX);
}
/*
_
next prev parent reply other threads:[~2007-11-08 0:19 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-07 22:47 compat_sys_times() bogus until jiffies >= 0 David Brown
2007-11-07 23:28 ` Andrew Morton
2007-11-08 0:18 ` Andrew Morton [this message]
2007-11-08 0:54 ` Andreas Schwab
2007-11-08 1:17 ` Andrew Morton
2007-11-08 1:53 ` Paul Mackerras
2007-11-08 2:09 ` David Miller
2007-11-08 10:20 ` Andreas Schwab
2007-11-08 14:42 ` Chris Friesen
2007-11-09 18:20 ` Ulrich Drepper
2007-12-20 11:36 ` Michael Kerrisk
2007-12-20 11:51 ` David Miller
2007-12-22 0:42 ` Andi Kleen
2007-12-22 1:41 ` David Miller
2007-12-22 1:45 ` David Miller
2007-12-22 1:53 ` Andi Kleen
2007-12-22 4:36 ` David Miller
2007-12-22 12:47 ` Andi Kleen
2007-12-22 1:49 ` Andi Kleen
2007-11-08 19:25 ` Denys Vlasenko
2007-11-08 3:07 ` Andrew Morton
2007-11-08 3:13 ` David Miller
2007-11-08 5:15 ` Paul Mackerras
2007-11-08 6:24 ` David Miller
2007-11-08 4:59 ` Paul Mackerras
2007-11-08 5:20 ` Andrew Morton
2007-11-08 5:36 ` Paul Mackerras
2007-11-08 6:12 ` Andrew Morton
2007-11-08 6:25 ` David Miller
2007-11-08 7:09 ` Andrew Morton
2007-11-08 7:14 ` David Miller
2007-11-08 8:53 ` Paul Mackerras
2007-11-08 6:22 ` David Miller
2007-11-08 19:27 ` Denys Vlasenko
2007-11-08 0:50 ` David Miller
2007-11-08 1:13 ` Andrew Morton
2007-11-08 6:00 ` David Brown
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=20071107161853.044b6e8f.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@davidb.org \
--cc=mtk-manpages@gmx.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox