times(2) misbehaviour

Joakim Tjernlund joakim.tjernlund at transmode.se
Tue Feb 2 13:14:30 UTC 2010


Julien Boibessot <julien.boibessot at free.fr> wrote on 2010/02/02 13:46:35:
>
> Joakim Tjernlund a écrit :
> >
> > Oh yes, been there done that :)
> > Most arch's has this bug in linux(ppc in recent 2.6 does not).
> >
> From my understanding all 32 bits arch that do not have Linux sys_call
> error codes separated from return values.

Yes, from 2.6.29. Before that no arch was correct.

> > Not sure I like:
> >
> >> +  /* Return value (clock_t) -1 signals an error to userspace, but if there
> >> +     wasn't any, return 0 instead. */
> >> +  if (ret == (clock_t) -1)
> >> +    return (clock_t) 0;
> >>
> > this will skip ahead a tick
> >
> yes you will skip one tick once during your system lifetime. But with
> current implementation 4096 ticks are skipped after 5 minutes of system
> uptime ;-)

yes, not bad but it also mean that you cannot trust times(2) to
be strict monotonic. For the vast majority that won't matter.

> > Does the patch work for times(NULL) too? Perhaps EFAULT
> > can not be returned in this case?
> >
> times(NULL) returns a correct tick value with my patch. not good ?

It will most of the time, but if you are unlucky and hit the exact tick
that returns -EFAULT you will SEGV. Better to test if buf is NULL and
skip the whole test. One could consider a #define NO_BROKEN times too
so arch's that behave don't have to do the extra work.
The corrected times(2) impl. in the kernel will return -1 so
I think the emulated version should too.

    Jocke



More information about the uClibc mailing list