Date: Sat, 18 Sep 2004 08:55:01 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: current@FreeBSD.org Subject: Re: 5.3-RELEASE TODO Message-ID: <Pine.NEB.3.96L.1040918085237.88212A-100000@fledge.watson.org> In-Reply-To: <20040918051758.GA18656@odin.ac.hmc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 17 Sep 2004, Brooks Davis wrote: > 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 wil= l > > > need before doing any kind of allocation, hence the double loop and t= he > > > 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 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: ifconf: 16384 space ifconf: 2048 space ifconf: 2048 space ifconf: 4095 space This is from a printf of ifc->ifc_len before the loop begins. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040918085237.88212A-100000>