Re: 5.3-RELEASE TODO

From: Brooks Davis <brooks_at_one-eyed-alien.net>
Date: Sat, 18 Sep 2004 10:12:16 -0700
On Sat, Sep 18, 2004 at 08:55:01AM -0400, Robert Watson wrote:
> 
> 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_at_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.

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

-- 
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

Received on Sat Sep 18 2004 - 15:10:39 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:12 UTC