lkml.org 
[lkml]   [2005]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] sys_epoll_wait() timeout saga ...
Hi Davide,

On Fri, Sep 23, 2005 at 11:13:30AM -0700, Davide Libenzi wrote:
>
> The sys_epoll_wait() function was not handling correctly negative
> timeouts (besides -1), and like sys_poll(), was comparing millisec to
> secs in testing the upper timeout limit.
>
>
> Signed-off-by: Davide Libenzi <davidel@xmailserver.org>
>
>
> - Davide

> --- a/fs/eventpoll.c 2005-09-23 10:56:57.000000000 -0700
> +++ b/fs/eventpoll.c 2005-09-23 11:00:06.000000000 -0700
> @@ -1507,7 +1507,7 @@
> * and the overflow condition. The passed timeout is in milliseconds,
> * that why (t * HZ) / 1000.
> */
> - jtimeout = timeout == -1 || timeout > (MAX_SCHEDULE_TIMEOUT - 1000) / HZ ?
> + jtimeout = timeout < 0 || (timeout / 1000) >= (MAX_SCHEDULE_TIMEOUT / HZ) ?
> MAX_SCHEDULE_TIMEOUT: (timeout * HZ + 999) / 1000;

Here, I'm not certain that gcc will optimize the divide. It would be better
anyway to write this which is equivalent, and a pure integer comparison :

+ jtimeout = timeout < 0 || timeout >= 1000 * MAX_SCHEDULE_TIMEOUT / HZ ?
> MAX_SCHEDULE_TIMEOUT: (timeout * HZ + 999) / 1000;

gcc will also spit a warning if the constant is too big for an int,
depending on MAX_SCHEDULE_TIMEOUT and HZ, while in the previous case,
it would remain silent, and possibly, timeout/1000 would never reach
the limit.

Regards,
Willy

-
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/

\
 
 \ /
  Last update: 2005-09-24 06:15    [W:0.065 / U:1.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site