Date: Wed, 3 Jun 1998 06:00:02 -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: <199806031300.GAA21793@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806031300.GAA21793>