From root@twwells.com  Tue Oct 30 13:43:03 2001
Return-Path: <root@twwells.com>
Received: from mail.twwells.com (mail.twwells.com [206.55.70.12])
	by hub.freebsd.org (Postfix) with ESMTP id 640CF37B403
	for <freebsd-gnats-submit@freebsd.org>; Tue, 30 Oct 2001 13:43:02 -0800 (PST)
Received: from mail (helo=mail.twwells.com)
	by mail.twwells.com with local-bsmtp (Exim 3.32 #1)
	id 15ygf2-000CVU-00
	for freebsd-gnats-submit@freebsd.org; Tue, 30 Oct 2001 15:43:04 -0600
Received: from server.twwells.com ( [206.55.70.12] )
	by mail.twwells.com via tcp with esmtp
	id 3bdf1eaf-00bba9; Tue, 30 Oct 2001 21:42:07 +0000
Received: from root by server.twwells.com with local (Exim 3.33 #1)
	id 15yge6-000CUo-00
	for FreeBSD-gnats-submit@freebsd.org; Tue, 30 Oct 2001 15:42:06 -0600
Message-Id: <E15yge6-000CUo-00@server.twwells.com>
Date: Tue, 30 Oct 2001 15:42:06 -0600
From: Bourne-again Superuser <toor@twwells.com>
Reply-To: Bourne-again Superuser <toor@twwells.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: socket calls can return undocumented EINVAL
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         31647
>Category:       kern
>Synopsis:       [libc] socket calls can return undocumented EINVAL
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-net
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Oct 30 13:50:00 PST 2001
>Closed-Date:    
>Last-Modified:  Mon Mar 23 21:41:39 UTC 2009
>Originator:     Bourne-again Superuser
>Release:        FreeBSD 4.4-STABLE i386
>Organization:
>Environment:
System: FreeBSD server.twwells.com 4.4-STABLE FreeBSD 4.4-STABLE #0: Fri Oct 12 02:24:59 CDT 2001 root@server.twwells.com:/usr/obj/usr/src/sys/SERVER_SMP i386
>Description:
	A rather large number of tcp routines begin with
	COMMON_START(), which can cause them to return EINVAL when
	inp_ppcb is null. In at least one system call, shutdown(),
	EINVAL is supposed only to mean that the second parameter
	is unacceptable.
>How-To-Repeat:
	Read the relevant source and documents.
>Fix:
	Either the documentation needs changing or the code does.
>Release-Note:
>Audit-Trail:

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: Bourne-again Superuser <toor@twwells.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: kern/31647: socket calls can return undocumented EINVAL
Date: Tue, 30 Oct 2001 17:26:43 -0500 (EST)

 <<On Tue, 30 Oct 2001 15:42:06 -0600, Bourne-again Superuser <toor@twwells.com> said:
 
 > 	A rather large number of tcp routines begin with
 > 	COMMON_START(), which can cause them to return EINVAL when
 > 	inp_ppcb is null.
 
 This is supposed to be a ``can't happen'' condition.
 
 -GAWollman
 

From: Mail Administration <mail@twwells.com>
To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman)
Cc: toor@twwells.com (Bourne-again Superuser),
	FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/31647: socket calls can return undocumented EINVAL
Date: Wed, 31 Oct 2001 02:59:39 -0600 (CST)

 > <<On Tue, 30 Oct 2001 15:42:06 -0600, Bourne-again Superuser <toor@twwells.com> said:
 > >     A rather large number of tcp routines begin with
 > >     COMMON_START(), which can cause them to return EINVAL when
 > >     inp_ppcb is null.
 >
 > This is supposed to be a ``can't happen'' condition.
 
 Just to be sure, I cvsupped to -stable tonight and tried again. I
 am able to reliably get shutdown() to return EINVAL when its "how"
 parameter is SHUT_WR. So unless there's somewhere else that it can
 return EINVAL, this "can't happen" actually does happen.
 
 Is there anything I might do that would be useful in tracking down
 the problem?

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: Mail Administration <mail@twwells.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/31647: socket calls can return undocumented EINVAL
Date: Wed, 31 Oct 2001 11:43:37 -0500 (EST)

 <<On Wed, 31 Oct 2001 02:59:39 -0600 (CST), Mail Administration <mail@twwells.com> said:
 
 > Just to be sure, I cvsupped to -stable tonight and tried again. I
 > am able to reliably get shutdown() to return EINVAL when its "how"
 > parameter is SHUT_WR.
 
 > Is there anything I might do that would be useful in tracking down
 > the problem?
 
 Please provide the procedure or scenario you used to reproduce the
 problem.
 
 -GAWollman
 

From: Mail Administration <mail@twwells.com>
To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman)
Cc: mail@twwells.com (Mail Administration),
	FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/31647: socket calls can return undocumented EINVAL
Date: Wed, 31 Oct 2001 15:41:53 -0600 (CST)

 > <<On Wed, 31 Oct 2001 02:59:39 -0600 (CST), Mail Administration <mail@twwells.com> said:
 > > Just to be sure, I cvsupped to -stable tonight and tried again. I
 > > am able to reliably get shutdown() to return EINVAL when its "how"
 > > parameter is SHUT_WR.
 >
 > > Is there anything I might do that would be useful in tracking down
 > > the problem?
 >
 > Please provide the procedure or scenario you used to reproduce the
 > problem.
 
 There are three pieces: apache, my program, and ab. I set them all
 up on one machine so I could stress test the program. The only odd
 things I've done on the test machine are to set all file systems
 noatime and net.inet.tcp.msl=100. That latter, to keep the system
 from having too many TIME_WAIT connections.
 
 My program is functioning as a TCP proxy between ab and apache; I
 simply start ab with a URL pointing to the proxy's port and it
 redirects the session to apache. (They're all using 127.0.0.1, in
 case that's significant.) I don't get a failure immediately or at
 a specific time but I'm pretty much guaranteed to get a failure
 reasonably quickly. The failure is in the proxy itself. If I make
 the proxy ignore the error, everything works as expected.
 
 I was able to ktrace a failure. It shows a successful writev() to
 the client socket immediately followed by a shutdown() that
 returns EINVAL.
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: brucec 
Responsible-Changed-When: Mon Mar 23 21:41:14 UTC 2009 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=31647 
>Unformatted:
