Date: Fri, 17 Sep 2004 21:30:19 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) To: Brooks Davis <brooks@one-eyed-alien.net> Cc: current@FreeBSD.org Subject: Re: 5.3-RELEASE TODO Message-ID: <xzpllf8n16c.fsf@dwp.des.no> In-Reply-To: <20040917184817.GA22747@odin.ac.hmc.edu> (Brooks Davis's message of "Fri, 17 Sep 2004 11:48:17 -0700") References: <200409170741.i8H7fGV3011078@pooker.samsco.org> <20040917162535.GA5750@odin.ac.hmc.edu> <xzpu0twn5gz.fsf@dwp.des.no> <20040917184817.GA22747@odin.ac.hmc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Brooks Davis <brooks@one-eyed-alien.net> writes:
> On Fri, Sep 17, 2004 at 07:57:32PM +0200, Dag-Erling Smørgrav wrote:
> > struct sbuf *sb = 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 = sbuf_new(NULL, NULL, ifc->ifc_len + 1, SBUF_FIXEDLEN);
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
--
Dag-Erling Smørgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpllf8n16c.fsf>