From owner-freebsd-bugs Tue Jun 2 20:40:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA12386 for freebsd-bugs-outgoing; Tue, 2 Jun 1998 20:40: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 UAA12374 for ; Tue, 2 Jun 1998 20:40:39 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id UAA18610; Tue, 2 Jun 1998 20:40:01 -0700 (PDT) Date: Tue, 2 Jun 1998 20:40:01 -0700 (PDT) Message-Id: <199806030340.UAA18610@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: David Greenman Subject: Re: kern/6837: in_setpeeraddr() and in_setsockaddr() block on memory Reply-To: David Greenman 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 To: cmetz@inner.net Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/6837: in_setpeeraddr() and in_setsockaddr() block on memory Date: Tue, 02 Jun 1998 20:37:35 -0700 >These two functions now MALLOC their address parameter inline rather >than having the address buffer passed in. They do so with M_WAITOK, >which will tsleep() the process indefinitely waiting for the memory. >Granted, if you're that short on memory on a BSD system, you'll have >bigger problems, but IMO these functions should kick ENOBUFS back up the >stack and get out of kernel mode (thus freeing up some other buffer >memory) rather than block the process. Why do you think it should be that way? It won't be an indefinate wait, just a wait until memory is freed up which shouldn't be for very long. -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