NetBSD Problem Report #11287

Received: (qmail 8949 invoked from network); 22 Oct 2000 16:56:16 -0000
Message-Id: <200010221656.e9MGuBp16142@idris.laine.org>
Date: Sun, 22 Oct 2000 12:56:11 -0400 (EDT)
From: lainestump@rcn.com
Reply-To: lainestump@rcn.com
To: gnats-bugs@gnats.netbsd.org
Subject: select() fails when timeout is > 100,000,000 sec.
X-Send-Pr-Version: 3.95

>Number:         11287
>Category:       kern
>Synopsis:       select() fails when timeout is > 100,000,000 sec.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Oct 22 16:57:00 +0000 2000
>Closed-Date:    Tue Jan 22 22:59:14 +0000 2008
>Last-Modified:  Tue Jan 22 22:59:14 +0000 2008
>Originator:     Laine Stump
>Release:        NetBSD 1.5_ALPHA2-i386 as of Oct 18, 2000
>Organization:
>Environment:

System: NetBSD idris.laine.org 1.5_ALPHA2 NetBSD 1.5_ALPHA2 (GENERIC-lrs) #0: Thu Oct 19 01:49:50 EDT 2000 laine@idris.laine.org:/drive2/src/src/sys/arch/i386/compile/GENERIC-lrs i386


>Description:

If select() is called with a tv_sec > 100000000, it will fail with
EINVAL.

This is especially bad in the case of dhclient, which does a select
with timeout = the lease expire time. If the lease is extremely long
(as it is in the case of RCN cable modem service), select will instead
return immediately with EINVAL, causing dhclient to chew up all
available CPU time.

The problem is that sys_select() calls kern_time.c:itimerfix(), which
returns EINVAL if tv_sec is > 100000000. This seems rather arbitrary -
maybe I *want* to set a timeout of 1000000001 seconds!

Note that I've set this at a high priority because it is the cause of
a serious problem in at least two running systems (mine, and Peter
Seebach's) - the system is really unusable for me without a patch, and
the same will probably happen to others (anybody else with RCN cable
modem service, at least).

>How-To-Repeat:

1) write a short program that calls select with a timeout of 100,000,001 sec.

2) run dhclient and get a lease with (for example) a 30 year
expiration, watch dhclient eat all your CPU time.


>Fix:

Several possibilities, and I'm not qualified to decide which is best (although I have an opinion ;-):

1) modify select to not call itimerfix(), and to do its own limit
   checking/setting (in case there are other places that call
   itimerfix and really do need this behavior)?

2) modify itimerfix() to silently reset tv_sec if it's too large
   (sounds like a very bad idea to me).

3) modify itimerfix() to not modify anything, but also not return
   EINVAL for extremely large settings for tv_sec (this seems most
   logical to me, but there may be some other use of itimerfix() that
   I'm not aware of which depends on this behavior).

4) document in the select manpage (and for any other function that
   sends timevals through itimerfix() that the maximum value for
   tv_sec is 100,000,000 (yeah, right).

>Release-Note:
>Audit-Trail:

From: "Martin J. Laubach" <mjl@emsi.priv.at>
To: lainestump@rcn.com, gnats-bugs@netbsd.org
Cc:  
Subject: Re: kern/11287: select() fails when timeout is > 100,000,000 sec.
Date: Sun, 22 Oct 2000 23:31:23 +0200 (CEST)

 | >Synopsis:       select() fails when timeout is > 100,000,000 sec.

   Just as additional pointer, there is a FreeBSD PR on exactly that
 problem, mentioning a bit of SUS and the rationale behind this limit.
 That is FreeBSD kern/18909.

 	mjl

State-Changed-From-To: open->analyzed 
State-Changed-By: tv 
State-Changed-When: Fri Nov 3 10:09:07 PST 2000 
State-Changed-Why:  
The dhclient corner case has been worked around, so the priority on this PR 
has been lowered for a future fix after 1.5. 
State-Changed-From-To: analyzed->closed
State-Changed-By: dholland@narn.netbsd.org
State-Changed-When: Tue, 22 Jan 2008 22:59:14 +0000
State-Changed-Why:
This appears to have been fixed.


>Unformatted:

Home	PR Database Search