From owner-cvs-all@FreeBSD.ORG Wed Sep 1 01:02:29 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFB2616A4CE; Wed, 1 Sep 2004 01:02:29 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD6BA43D39; Wed, 1 Sep 2004 01:02:29 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8112fsJ007521; Tue, 31 Aug 2004 18:02:41 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8112fYa007520; Tue, 31 Aug 2004 18:02:41 -0700 Date: Tue, 31 Aug 2004 18:02:41 -0700 From: Brooks Davis To: Peter Wemm Message-ID: <20040901010241.GC25779@odin.ac.hmc.edu> References: <200408300629.i7U6TQ5C088279@repoman.freebsd.org> <200408301729.22348.peter@wemm.org> <20040831004311.GA29938@odin.ac.hmc.edu> <200408311746.50735.peter@wemm.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NU0Ex4SbNnrxsi6C" Content-Disposition: inline In-Reply-To: <200408311746.50735.peter@wemm.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Brooks Davis cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Andrew Gallatin cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src UPDATING src/sys/sys param.h src/sys/net if.c if.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 01:02:30 -0000 --NU0Ex4SbNnrxsi6C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 05:46:50PM -0700, Peter Wemm wrote: > On Monday 30 August 2004 05:43 pm, Brooks Davis wrote: > > On Mon, Aug 30, 2004 at 05:29:22PM -0700, Peter Wemm wrote: > > > On Monday 30 August 2004 02:53 pm, Brooks Davis wrote: > > > > On Mon, Aug 30, 2004 at 05:34:23PM -0400, Andrew Gallatin wrote: > > > > > Brooks Davis writes: > > > > > > I don't think so. The main offenders will be programs that > > > > > > walk the interface list via libkvm and programs that use > > > > > > struct if_data. ifconfig does neither. If you haven't > > > > > > recompiled a module, a non-working ifconfig might result if > > > > > > by some miracle you didn't get a panic on attach. > > > > > > > > > > ppc does not even build modules, so that's out. An older > > > > > ifconfig pukes, while a new one works, so some sort of > > > > > kernel/userland ABI must have changed in the last week. Has > > > > > the data exported by sysctl changed recently? > > > > > > > > I think I found it, at least partially. The issue is struct > > > > if_msghdr which is used by ifconfig. It contains a struct > > > > if_data. It has grown by a struct timeval. The weird thing is > > > > that this shouldn't be a problem becuase if_msghdr has a length > > > > and my addition was to the end so ifconfig should be able to skip > > > > over it, but it doesn't seem to actually work. > > > > > > It is broken on amd64 too, FWIW. > > > > If if_msghdr is the problem, it will be broken on all platforms and a > > rebuild of everything thing should fix it. I don't know why ifconfig > > is having a problem with the extension of if_msghdr. It shouldn't > > care since the format is unchanged other then the addition of a > > structure at the very end and the ifm_msglen member appears to be > > used correct to advance through the array passed by the sysctl. >=20 > Actually, I more want to know why it didn't work. But I haven't figured= =20 > out where the message lengths are even getting set, let alone=20 > (mis?)used by ifconfig. The if_msghdrs are used in the loop that starts around line 582 in ifconfig.c. That seems to correct. The length seems to be set in in net/rtsock.c in the rt_msg1 and rt_msg2 functions. The reason it's so darn hard to find is that routing messages are defined by different structs with the same first several members. Due to the naming of the members, that renders grep useless. :-( I can't help but think someone was too clever for their own good. I still don't see why it's breaking though since that should set the values. The only thing I can think of is that there's a dependency tracking bug somewhere, but that seems unlikely which would seem to indicate that I'm not on to the real cause yet. :-( -- 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 --NU0Ex4SbNnrxsi6C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNR+xXY6L6fI4GtQRAvQkAKCil4uoxgkNUVJwyv6cdnPZoigRdQCeIAlt 1Vsy103dLz03CWaIvaGDDGE= =usrO -----END PGP SIGNATURE----- --NU0Ex4SbNnrxsi6C--