times(2) misbehaviour

[Will Newton]

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.