From owner-svn-src-all@freebsd.org Mon Jan 8 16:18:36 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB7D5E75500 for ; Mon, 8 Jan 2018 16:18:36 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B9C383134 for ; Mon, 8 Jan 2018 16:18:36 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 84a4b9c7-f48f-11e7-8486-0934409070aa X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 84a4b9c7-f48f-11e7-8486-0934409070aa; Mon, 08 Jan 2018 16:18:10 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w08GISK5002547; Mon, 8 Jan 2018 09:18:28 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1515428308.44630.2.camel@freebsd.org> Subject: Re: svn commit: r327684 - in head/sys/compat: cloudabi32 cloudabi64 From: Ian Lepore To: Warner Losh , Pedro Giffuni Cc: Ed Schouten , Andrew Turner , Ed Schouten , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Mon, 08 Jan 2018 09:18:28 -0700 In-Reply-To: References: <201801072238.w07McjLP099234@repo.freebsd.org> <8D8CA434-2A87-44D9-AC27-5166802FBBC2@fubar.geek.nz> <0a6ad324-46f2-9270-5abd-dbc3e734cc8b@FreeBSD.org> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 16:18:36 -0000 On Mon, 2018-01-08 at 09:13 -0700, Warner Losh wrote: > On Jan 8, 2018 8:37 AM, "Pedro Giffuni" wrote: > > > On 01/08/18 10:13, Ed Schouten wrote: > > > > > Hi Andrew, > > > > 2018-01-08 8:37 GMT+01:00 Andrew Turner : > > > > > > > > Wonąt this lead to a NULL pointer dereference on overflow? mallocarray > > > can return NULL even with M_WAITOK. > > > > > Yes, it will, but an overflow shouldn't happen in the first place. > > ri_data_len is compared with UIO_MAXIOV a few lines above. Even if an > > overflow would happen, this would cause a kernel panic due to a NULL > > pointer dereference later on, which is likely easier to debug than > > some piece of code that overruns a buffer. > > > > In this case, mallocarray() is preferred, because it makes it more > > obvious that we're allocating a buffer that is accessed as an array, > > as opposed to single structure. > > > > OK... > The behavior of mallocarray() somewhat inconsistent with malloc(9), > realloc(9) and reallocf(9) but this is clearly documented., so we just > assume the developer knows what he/she is doing :). > > > This is one reason it didn't go in before... the error semantics suck... we > re are a poor match for existing code. > > Warner Yeah, having a bunch of functions with malloc in the name, all taking the same M_WAITOK flag, but that flag has different implications for calling code in regards to just one of the malloc functions... that's just a recipe for creating bugs.  It makes this whole function a bad idea. -- Ian