From owner-freebsd-bugs  Wed Jun  3 06:00:46 1998
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id GAA07017
          for freebsd-bugs-outgoing; Wed, 3 Jun 1998 06:00:46 -0700 (PDT)
          (envelope-from owner-freebsd-bugs@FreeBSD.ORG)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA07012
          for <freebsd-bugs@FreeBSD.org>; Wed, 3 Jun 1998 06:00:42 -0700 (PDT)
          (envelope-from gnats@FreeBSD.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.8.8/8.8.5) id GAA21793;
	Wed, 3 Jun 1998 06:00:02 -0700 (PDT)
Date: Wed, 3 Jun 1998 06:00:02 -0700 (PDT)
Message-Id: <199806031300.GAA21793@freefall.freebsd.org>
To: freebsd-bugs@FreeBSD.ORG
From: David Greenman <dg@root.com>
Subject: Re: kern/6837: in_setpeeraddr() and in_setsockaddr() block on memory 
Reply-To: David Greenman <dg@root.com>
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

The following reply was made to PR kern/6837; it has been noted by GNATS.

From: David Greenman <dg@root.com>
To: Craig Metz <cmetz@inner.net>
Cc: freebsd-gnats-submit@FreeBSD.ORG, wollman@FreeBSD.ORG
Subject: Re: kern/6837: in_setpeeraddr() and in_setsockaddr() block on memory 
Date: Wed, 03 Jun 1998 05:58:22 -0700

 >In message <199806031211.FAA22165@implode.root.com>, you write:
 >>>  In 4.4-Lite2, they did basically just that. Why did they change?
 >>
 >>   I believe this was a side effect of the elimination of using mbufs as
 >>containers for sockaddr data. I don't see a problem with changing the caller
 >>to malloc(), but perhaps Garrett might have a thought on this since he was
 >>the one to add the MALLOC there in the first place. Garrett?
 >
 >  Perhaps it's because only the PF-specific setsockaddr/setpeeraddr function
 >knows the exact size to allocate.
 
    There is a limit to how large the sockaddr can be, so the exact size
 doesn't need to be known.
 
 > Moving the malloc up a level in the
 >heirarchy won't actually change the problem of blocking or not if there's not
 >enough memory for the buffer to hold this, though.
 
    No, it won't change the problem of blocking for getpeername(), but the
 code you're adding is to the pcb.c function, yes? So the blocking won't be
 an issue.
    Why do you need to add code that is called at splnet to the in_set*addr
 functions in the first place?
 
 -DG
 
 David Greenman
 Co-founder/Principal Architect, The FreeBSD Project

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message