Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 May 2000 21:22:45 -0400 (EDT)
From:      Kelly Yancey <kbyanc@posi.net>
To:        David Malone <dwmalone@maths.tcd.ie>
Cc:        freebsd-bugs@FreeBSD.ORG
Subject:   Re: kern/18909: select(2) timeout limited to 100000000 seconds
Message-ID:  <Pine.BSF.4.05.10005302101050.64399-100000@kronos.networkrichmond.com>
In-Reply-To: <200005302220.PAA47200@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <dwmalone@maths.tcd.ie>
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10005302101050.64399-100000>