From owner-freebsd-bugs Tue May 30 18:22:57 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from kronos.networkrichmond.com (kronos.networkrichmond.com [64.240.180.22]) by hub.freebsd.org (Postfix) with ESMTP id 8F65837BE25 for ; Tue, 30 May 2000 18:22:49 -0700 (PDT) (envelope-from kbyanc@posi.net) X-Provider: Network Richmond, LLC. http://www.networkrichmond.com/ Received: from localhost (kbyanc@localhost) by kronos.networkrichmond.com (8.9.3/8.9.3/antispam) with ESMTP id VAA64876; Tue, 30 May 2000 21:22:45 -0400 (EDT) Date: Tue, 30 May 2000 21:22:45 -0400 (EDT) From: Kelly Yancey X-Sender: kbyanc@kronos.networkrichmond.com To: David Malone Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/18909: select(2) timeout limited to 100000000 seconds In-Reply-To: <200005302220.PAA47200@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 30 May 2000, David Malone wrote: > The following reply was made to PR kern/18909; it has been noted by GNATS. > > From: David Malone > To: freebsd-gnats-submit@FreeBSD.org, archie@whistle.com > Cc: > Subject: Re: kern/18909: select(2) timeout limited to 100000000 seconds > Date: Tue, 30 May 2000 23:15:20 +0100 > > Here is what "The Single UNIX Specification, Version 2" that I > downloaded about a year ago says: > > Implementations may place limitations on the maximum timeout > interval supported. On all implementations, the maximum timeout > interval supported will be at least 31 days. If the timeout > argument specifies a timeout interval greater than the > implementation-dependent maximum value, the maximum value will be > used as the actual timeout value. Implementations may also place > limitations on the granularity of timeout intervals. If the > requested timeout interval requires a finer granularity than the > implementation supports, the actual timeout interval will be > rounded up to the next supported value. > > So it looks the implimentation doesn't agree with this, and the > man page should probably say what the max timeout is. > > (Excerpt is from http://www.opennc.org/onlinepubs/7908799/xsh/select.html). > I read this to say that returning EINVAL (as reported in the submitted PR) is the Wrong Thing and that we should be rounding the interval down instead. The culprit is kern_time.c:itimerfix which is called by select, poll, and others to bomb if the time exceeds 10,000,000 seconds. Below is a patch which changes its behavior to match the Single Unix Spec quoted above. A grep on /usr/src/sys shows 11 references to itimerfix: i386/linux/linux_misc.c:486 kern/kern_event.c:541 kern/kern_threads.c:91 kern/kern_time.c:507 kern/kern_time.c:511 kern/sys_generic.c:671 kern/sys_generic.c:804 kern/vfs_aio.c:1549 kern/vfs_aio.c:2277 net/bpf.c:807 netncp/ncp_sock.c:206 So someone more wise will definately need to review this (simple) patch as it may have far-reaching affects. Kelly -- Kelly Yancey - kbyanc@posi.net - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ Index: kern_time.c =================================================================== RCS file: /home/cvs/src/sys/kern/kern_time.c,v retrieving revision 1.70 diff -u -r1.70 kern_time.c --- kern_time.c 2000/04/18 15:15:20 1.70 +++ kern_time.c 2000/05/31 01:15:09 @@ -580,9 +580,10 @@ struct timeval *tv; { - if (tv->tv_sec < 0 || tv->tv_sec > 100000000 || - tv->tv_usec < 0 || tv->tv_usec >= 1000000) + if (tv->tv_sec < 0 || tv->tv_usec < 0 || tv->tv_usec >= 1000000) return (EINVAL); + if (tv->tv_sec > 100000000) + tv->tv_sec = 100000000; if (tv->tv_sec == 0 && tv->tv_usec != 0 && tv->tv_usec < tick) tv->tv_usec = tick; return (0); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message