times(2) misbehaviour

Julien Boibessot julien.boibessot at free.fr
Sun Jan 31 19:33:39 UTC 2010


after a big bug hunt we also found that the implementation of the
"times" system call in uClibc 0.9.29/0.9.30 is problematic on some 32
bits architectures (arm926 in our case); like it was reported 2 years
ago by Will.

The fact that uClibc considers some Linux sys_times() return values as
errors makes some user space applications become crazy (Qt in our case):
when Linux "times" syscall's return value is inside uClibc errors range
(cf INTERNAL_SYSCALL_ERROR_P macro), uClibc forward a (-1) error code to
caller. An application may freeze during many seconds (40 if system tick
is 10ms), if it's event handling relies on times() accuracy. Problem
occurs after 5 minutes of system's running, when Linux tick timer value
reaches its limit on 32 bits systems.

glibc has a special handling for "times" syscall.
I have attached a patch that implements times in the same way as glibc.

Could maintainers of uClibc get inspired from that patch and do a
correction for this problem please ?

Thanks !

Denys Vlasenko a écrit :
> On Thursday 24 April 2008 21:43, Will Newton wrote:
>>>  > 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.
> I propose creating another wrapper for syscalls which never fail.
>>>  My take is that this syscall should be considered
>>>  as "never returning errors".
>> syscalls do return errors!
> What error can this particular syscall return? I see only one:
> EINVAL, when user passed invalid pointer to "struct tms".
> In this case, the program is buggy anyway.
> It probably won't help one iota that libc will pass EINVAL
> back in errno in this case. So why should we do that?
>>>  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.
> Yes, I understand that.
> I propose to fix it by interpreting all posiible return values
> as non-errors.
> --

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 001-sysdeps-common-do_not_handle_times_syscall_return_value_as_standard_errors.patch
Type: text/x-diff
Size: 2146 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20100131/49bfbf14/attachment.bin>

More information about the uClibc mailing list