Date: Sat, 18 Sep 2004 10:12:16 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: 5.3-RELEASE TODO Message-ID: <20040918171216.GA27533@odin.ac.hmc.edu> In-Reply-To: <Pine.NEB.3.96L.1040918085237.88212A-100000@fledge.watson.org> References: <20040918051758.GA18656@odin.ac.hmc.edu> <Pine.NEB.3.96L.1040918085237.88212A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 18, 2004 at 08:55:01AM -0400, Robert Watson wrote: >=20 > On Fri, 17 Sep 2004, Brooks Davis wrote: >=20 > > On Fri, Sep 17, 2004 at 09:30:19PM +0200, Dag-Erling Sm=F8rgrav wrote: > > > Brooks Davis <brooks@one-eyed-alien.net> writes: > > > > Thus, so you have to know how much space you w= ill > > > > need before doing any kind of allocation, hence the double loop and= the > > > > potential race. > > >=20 > > > Using sbufs removes the need for loop and greatly simplifies how you > > > deal with overflows. > >=20 > > Indeed it does. I'm not fully happy with the hardcoding of a maximum > > size, but I doubt anyone will hit it in practice. Here's a new and > > improved patch that makes a single pass and uses sbufs.=20 >=20 > Have you tried seeing just how many addresses you can add before > getifaddrs() fails to return the complete list? 128k seems like a lot, > but I instrumente ifconf() locally a couple of weeks ago when I first > became aware of this problem, and discovered that even on my notebook > (which has a wireless card with one IP, and an unused ethernet card) that > I see moderately large buffers being read from user space: >=20 > ifconf: 16384 space > ifconf: 2048 space > ifconf: 2048 space > ifconf: 4095 space >=20 > This is from a printf of ifc->ifc_len before the loop begins. Those allocations don't seem to make any sense. The actual space required is quite small. All you do is copy one struct ifreq out for each address, plus one for each interface with no addresses. The base size of a struct ifreq is 32 bytes and it extends to 34 for IPv6 addresses. The maximum size allowed by the data types is 273 (for a 255 byte address). Since I think IPv6 are the largest addresses used in practice, MAXPHYS is probably not too bad, though it does put a new cap on the number of interfaces at ~4k. If we want to keep kernel allocations small and allow all the itnerfaces to be reliably reported, we probably need to go back to my origional plan where we loop repeatidly. I might do it differently by allocating up to MAXPHYS and only reallocating if we overflow. That would avoid doing it twice (or more) on normal machines while still being correct. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBTGxvXY6L6fI4GtQRAo85AJ9xxaQfSuJhbHgGexVG8vYYboFmyQCfdFbf JylslNS7bGzYBK6fvSnjmss= =Ac7B -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040918171216.GA27533>