From wollman@khavrinen.lcs.mit.edu  Tue Jul 23 12:52:42 1996
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.26.0.162])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA07622
          for <FreeBSD-gnats-submit@freebsd.org>; Tue, 23 Jul 1996 12:52:40 -0700 (PDT)
Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.7.5/8.6.6) id PAA02018; Tue, 23 Jul 1996 15:52:34 -0400 (EDT)
Message-Id: <199607231952.PAA02018@khavrinen.lcs.mit.edu>
Date: Tue, 23 Jul 1996 15:52:34 -0400 (EDT)
From: "Garrett A. Wollman" <wollman@khavrinen.lcs.mit.edu>
Reply-To: wollman@khavrinen.lcs.mit.edu
To: FreeBSD-gnats-submit@freebsd.org
Subject: Non-bug in sosend()
X-Send-Pr-Version: 3.2

>Number:         1421
>Category:       kern
>Synopsis:       Non-bug in sosend()
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jul 23 13:00:00 PDT 1996
>Closed-Date:    Tue Apr 14 11:55:35 PDT 1998
>Last-Modified:  Tue Apr 14 11:56:06 PDT 1998
>Originator:     Garrett Wollman
>Release:        FreeBSD 2.2-CURRENT i386
>Organization:
MIT Laboratory for Computer Science
>Environment:

	-current as of 7/23, although I have no reason to believe that this
	bug has not existed for a very long time indeed.

>Description:

	While in the process of re-working sosend() for TCP, I noticed
	this odd bit of code:

	if (resid < 0)
		return (EINVAL);

	This is preceded by a comment explaining why resid is signed
	in the first place.  BUT, note that this code exits
	immediately without freeing `control', which it does in all
	other error cases.  (It also doesn't free `top' but that case
	is not relevant here.)

	Having noticed this, I then attempted to demonstrate the memory
	leak.  However, I determined that it was impossible to do so,
	because all of the possible entry points where a user program
	might set up its own `iovec' check for overflow when computing
	`uio->uio_resid' and trap the error before sosend() ever sees
	it.  This is true in particular of sendmsg(2), which is the
	only system call resulting in anything in `control' to begin
	with.  So, the entire test is a logical error and should be
	eliminated (or at least hidden under #ifdef DIAGNOSTIC).

	I seem to recall a time when this test was actually necessary.

>How-To-Repeat:

	Inspect the code.

>Fix:
	
	Well, it doesn't matter much, but it would not be a bad thing
	to #ifdef out the test.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: scrappy 
State-Changed-When: Tue Oct 22 21:54:09 PDT 1996 
State-Changed-Why:  

Confirm Status:  Non-bug in sosend() 

State-Changed-From-To: feedback->suspended 
State-Changed-By: wollman 
State-Changed-When: Wed Oct 23 08:49:28 PDT 1996 
State-Changed-Why:  
It's a curiosity that should be documented as a possible 
future bug. 
State-Changed-From-To: suspended->closed 
State-Changed-By: phk 
State-Changed-When: Tue Apr 14 11:55:35 PDT 1998 
State-Changed-Why:  
comment in code seems to disagree 
>Unformatted:
