From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 18:46:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A41516A4CE; Fri, 17 Sep 2004 18:46:51 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0707F43D1D; Fri, 17 Sep 2004 18:46:51 +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 i8HImHVK024853; Fri, 17 Sep 2004 11:48:17 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8HImHRo024852; Fri, 17 Sep 2004 11:48:17 -0700 Date: Fri, 17 Sep 2004 11:48:17 -0700 From: Brooks Davis To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20040917184817.GA22747@odin.ac.hmc.edu> References: <200409170741.i8H7fGV3011078@pooker.samsco.org> <20040917162535.GA5750@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: 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: re@FreeBSD.org cc: current@FreeBSD.org Subject: Re: 5.3-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 18:46:51 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 17, 2004 at 07:57:32PM +0200, Dag-Erling Sm=F8rgrav wrote: > Brooks Davis writes: > > I've got a patch for this one. If someone will review it, I will commit > > it to HEAD for further testing. >=20 > you shouldn't call malloc() with M_NOWAIT unless you absolutely must, > and in this case you don't. Oops, that's a bug. I'll fix it before I commit. > there's nothing to prevent the ifconf data from growing between the > first and second pass, since you're not holding the lock. you'd end > up overflowing ifrbuf. The space variable insures that you won't overflow just as it did before when the user provided an undersized buffer. There is a race that might be worth fixing where the size can increase and more or more addresses/interfaces at the end won't get written out, but there isn't an overflow. The only way I can see to fix it is to check at the end of the loop and make sure that we added all items in the buffer or used as much space as the user gave us. If didn't do that, we need to start over (zero buflen, reset space, free ifrbuf, and goto again). Using sbufs as you suggest would probably make things a bit more clear, but I believe what I've got works. > what I suggest you do is: >=20 > struct sbuf *sb =3D sbuf_new(NULL, NULL, size, ifc->ifc_len + 1); What are you trying to do here? Unless my manpages are wrong, the fourth arg is flags. Do you mean to set SBUF_FIXEDLEN? I think you would have to to avoid a new LOR. Also, it is not safe to trust ifc->ifc_len for allocations because it is provided by potentially unpriveleged users. 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. Thanks, 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 --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBSzFxXY6L6fI4GtQRAvDwAJ9RrQ1ZAzSXhEb9MiZR+ozGzi2boACeKk6G v5mxOK4tnytYIO9V0b7z0KA= =K7eX -----END PGP SIGNATURE----- --ibTvN161/egqYuK8--