Bug 31647

Summary:	[libc] socket calls can return undocumented EINVAL
Product:	Base System	Reporter:	Bourne-again Superuser <toor>
Component:	kern	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Open ---
Severity:	Affects Only Me
Priority:	Normal
Version:	4.4-STABLE
Hardware:	Any
OS:	Any

Description Bourne-again Superuser 2001-10-30 21:50:00 UTC

	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.

Fix: 

Either the documentation needs changing or the code does.
How-To-Repeat: 	Read the relevant source and documents.

Comment 1 Garrett A. Wollman 2001-10-30 22:26:43 UTC

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

Comment 2 mail 2001-10-31 08:59:39 UTC

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

Comment 3 Garrett A. Wollman 2001-10-31 16:43:37 UTC

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

Comment 4 mail 2001-10-31 21:41:53 UTC

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

Comment 5 Bruce Cran freebsd_committer

2009-03-23 21:41:14 UTC

Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s).

Comment 6 Eitan Adler freebsd_committer

2017-12-31 08:00:23 UTC

For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped