Skip site navigation (1)Skip section navigation (2)
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>