From owner-freebsd-bugs Wed Jun 3 05:00:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA28483 for freebsd-bugs-outgoing; Wed, 3 Jun 1998 05:00:41 -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 FAA28476 for ; Wed, 3 Jun 1998 05:00:40 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id FAA21557; Wed, 3 Jun 1998 05:00:01 -0700 (PDT) Date: Wed, 3 Jun 1998 05:00:01 -0700 (PDT) Message-Id: <199806031200.FAA21557@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: Craig Metz Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/6837: in_setpeeraddr() and in_setsockaddr() block on memory Date: Wed, 03 Jun 1998 04:59:40 -0700 > If you do it M_WAIT style, the kernel tsleep()s the process, and the app >doesn't have any choice. It sleeps, possibly for a long time. By the time it >wakes up, given many typical places where getpeername()/getsockname() are used, >the returned value will be irrelevant. In many cases the delay won't be for more than a few microseconds while the pagedaemon wakes up and frees some cruft. In the worst case, some pages need to be pushed to swap, but even that should be less than a second of wait, so I don't see your argument about client retries. I really don't think it is a good idea to make this non-blocking. > The other, far easier to explain answer, is that we're putting some code in >there for IPv6 support that makes the malloc() happen at splnet(), and >tsleep()ing at such a priority is not good. That would be bad, but I don't think the solution is to make it fail on temporary resource shortages. I think a better solution would be to change the functions to take an already (m)alloced struct sockaddr_in and change the callers (I think there are only two) to accomodate. -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