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>
index | next in thread | previous in thread | raw e-mail
On Fri, 17 Sep 2004, Brooks Davis wrote: > On Fri, Sep 17, 2004 at 09:30:19PM +0200, Dag-Erling Smørgrav wrote: > > Brooks Davis <brooks@one-eyed-alien.net> writes: > > > Thus, so you have to know how much space you will > > > need before doing any kind of allocation, hence the double loop and the > > > potential race. > > > > Using sbufs removes the need for loop and greatly simplifies how you > > deal with overflows. > > 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. 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 Researchhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040918085237.88212A-100000>