times(2) misbehaviour
Will Newton
will.newton at gmail.com
Thu Apr 24 19:43:36 UTC 2008
On Thu, Apr 24, 2008 at 8:20 PM, Denys Vlasenko
<vda.linux at googlemail.com> wrote:
>
> On Thursday 24 April 2008 14:39, Will Newton wrote:
> > Hi,
> >
> > It looks to me as if times(2) is broken with Linux 2.6 on a 32bit
> > arch. Can anyone confirm if this analysis is correct?
> >
> > Looking at sys_times in the 2.6 kernel it returns like this:
> >
> > return (long) jiffies_64_to_clock_t(get_jiffies_64());
> >
> > On a 32bit arch that takes the bottom 32bits of a 64bit value.
> >
> > The system call wrappers in uClibc then examine the return code of the
> > system call and if it is greater than a certain unsigned value assumes
> > it is an errno value (negative). e.g. for arm:
> >
> > #undef INTERNAL_SYSCALL_ERROR_P
> > #define INTERNAL_SYSCALL_ERROR_P(val, err) \
> > ((unsigned int) (val) >= 0xfffff001u)
> >
> > This is effectively testing the bottom 32bits of jiffies_64 against
> > the largest known errno value which occasionally will be true even
> > when no error has been returned.
>
> Just delete the check for error.
The check is in generic syscall wrappers. glibc does exactly the same thing.
> My take is that this syscall should be considered
> as "never returning errors".
syscalls do return errors!
> The only programs which will see the difference are buggy already
> since they pass invalid pointer to kernel.
The case I am interested in is when a valid pointer is passed in but
the value of the low 32bits of jiffies_64 returned is being
interpreted as an error.
More information about the uClibc
mailing list