From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 19:30:21 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 2E35D16A4CE; Fri, 17 Sep 2004 19:30:21 +0000 (GMT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B467443D41; Fri, 17 Sep 2004 19:30:20 +0000 (GMT) (envelope-from des@des.no) Received: from dwp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id DB01E1F95; Fri, 17 Sep 2004 21:30:59 +0200 (MEST) Received: by dwp.des.no (Postfix, from userid 2602) id 895EDB85E; Fri, 17 Sep 2004 21:30:19 +0200 (CEST) To: Brooks Davis References: <200409170741.i8H7fGV3011078@pooker.samsco.org> <20040917162535.GA5750@odin.ac.hmc.edu> <20040917184817.GA22747@odin.ac.hmc.edu> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Fri, 17 Sep 2004 21:30:19 +0200 In-Reply-To: <20040917184817.GA22747@odin.ac.hmc.edu> (Brooks Davis's message of "Fri, 17 Sep 2004 11:48:17 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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 19:30:21 -0000 Brooks Davis writes: > On Fri, Sep 17, 2004 at 07:57:32PM +0200, Dag-Erling Sm=F8rgrav wrote: > > 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 meant struct sbuf *sb =3D sbuf_new(NULL, NULL, ifc->ifc_len + 1, SBUF_FIXEDL= EN); but I'm typing over a slow link and Meta-D'ed the wrong word. > I think you > would have to to avoid a new LOR. Of course. > 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. so just make sure before you call sbuf_new() that ifc_len is reasonable (e.g. < MAXPHYS) > 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. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no