Date: Wed, 3 Jun 1998 05:00:01 -0700 (PDT) From: David Greenman <dg@root.com> To: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/6837: in_setpeeraddr() and in_setsockaddr() block on memory Message-ID: <199806031200.FAA21557@freefall.freebsd.org>
index | next in thread | raw e-mail
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
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806031200.FAA21557>