Andrew Morton wrote:
> Andrew Morton <akpm@digeo.com> wrote:
>
>>errr, OK. This returns -EINVAL:
>>
>>#include <time.h>
>>
>>main()
>>{
>> struct timespec req;
>> struct timespec rem;
>> int ret;
>>
>> req.tv_sec = 5000000;
>> req.tv_nsec = 0;
>>
>> ret = nanosleep(&req, &rem);
>> if (ret)
>> perror("nanosleep");
>>}
>>
>
>
> OK, I give up.
>
> /*
> * This is a considered response, not exactly in
> * line with the standard (in fact it is silent on
> * possible overflows). We assume such a large
> * value is ALMOST always a programming error and
> * try not to compound it by setting a really dumb
> * value.
> */
> return -EINVAL;
>
> George, RH7.3 and RH8.0 cron daemons are triggering this (trying to sleep
> for 4,500,000 seconds) and it causes them to go into a busy loop.
>
> I think we need to just sleep for as long as we can and return an
> appropriate partial result.
>
>
Linus has fixed the problem cron showed up, so.
Lets consider this one on its own merits. What SHOULD sleep do when
asked to sleep for MAX_INT number of jiffies or more, i.e. when
jiffies overflows? My notion, above, it that it is clearly an error.
I suppose as HZ gets bigger, this argument will carry less weight,
but, still:
We have, I think, three choices:
1.) Error out as it does now,
2.) Sleep for MAX_INT and return ?????
3.) Sleep for MAX_INT and then sleep some more until the actual time
is reached.
2.) Requires, if we are to return other than OK, some way to flag that
the error happened.
3.) Likewise, requires more bits in the timer. If we went to a 64-bit
expire count, we could do the "right" thing, however it adds an int to
the size of the timer_struct.
So, folks, what is the _right_ thing to do here?
-g
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 15 2003 - 22:00:23 EST