From owner-svn-src-head@freebsd.org Mon Jan 8 16:29:43 2018 Return-Path: Delivered-To: svn-src-head@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 EA269E75FDE; Mon, 8 Jan 2018 16:29:43 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CE0683C06; Mon, 8 Jan 2018 16:29:43 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk0-x233.google.com with SMTP id w184so6657538qka.2; Mon, 08 Jan 2018 08:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=Im9tOxLlSvn4x7toFrNKTqrwnJWBNtBzr8+nJnv26Ug=; b=NRdP5O7fMCKczxgMGYbEo94auOqhWq97hbwf9FoEsqiXCJbZh/pKPsOEGVHDRR8mag I42KSlw6Tdv9xKDC+kXYKXJ6iFtQDwUKHsvONZWLbWMu/XqWOzQ5Mn9r6XbSISqLdQNR oKf7wfJ5znbmkP5yRlBsbM9uSIhdp/rroTCankcT3FZagXzATg05oLxEOHfWY+cJC2ZL 1FYeDdsECV4jQlv9odUdQcnWq7URXbMqaS9QGcGuSTklWkBK+FsS2RZ/sj7hH8g4Ebke pG0HfhHeQslK9tOCD6/5ZJWkdgRBfkcUBoV5AumqV4BM5sECeYCN4pbA76knAtnZ/SB+ APZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=Im9tOxLlSvn4x7toFrNKTqrwnJWBNtBzr8+nJnv26Ug=; b=ODHB3hc8oqDlRhyc1/sg53xIyiKYayXTTS+NBfmnq5z/t3SOgV9zvWOypiLpabIjJr CadESgf7kqDAujtAzfgwHOo+7hzTMDfymdI8/1HzKnLxLWRF810suNBQQDYQsLFw+GjS FUUZ2m0tVC6Q59QL/6stxGjW2vnNwZErojx36TMOuTmTZm48zF3EGyb+deyj63xS53vI E0ShYapwyrj3OB2wtrGmCqeWDlwlpKQ7qAvM7Zc3TKRgZkNAcPCPkL5ZB5rXqNyndme6 KxaDvCfijkWbSEzVPAMd9SFIEdAP5zgxhGuGt6cWyuL+Y1zMorOjG9c3GHTKEunmHKFI Ur7A== X-Gm-Message-State: AKwxytdUCOe+ph+92mycNeC4sKTzOPcN7QRGCOAT6vCdqDBFCg3FXf0n q7039yPC2niPrhfwruauamN4OOSd X-Google-Smtp-Source: ACJfBos+tSxR5x9fb7SUN8NXBIVAOgwBe/3uH6iF2UmdNo15o7Sy3ukER2R+aamjNIZu9qS2upNacA== X-Received: by 10.55.143.193 with SMTP id r184mr16078526qkd.193.1515428982259; Mon, 08 Jan 2018 08:29:42 -0800 (PST) Received: from raichu (toroon0560w-lp140-02-70-49-169-112.dsl.bell.ca. [70.49.169.112]) by smtp.gmail.com with ESMTPSA id m44sm7797504qtc.9.2018.01.08.08.29.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jan 2018 08:29:41 -0800 (PST) Sender: Mark Johnston Date: Mon, 8 Jan 2018 11:29:38 -0500 From: Mark Johnston To: Ian Lepore Cc: Warner Losh , Pedro Giffuni , Ed Schouten , Andrew Turner , Ed Schouten , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r327684 - in head/sys/compat: cloudabi32 cloudabi64 Message-ID: <20180108162938.GD2412@raichu> References: <201801072238.w07McjLP099234@repo.freebsd.org> <8D8CA434-2A87-44D9-AC27-5166802FBBC2@fubar.geek.nz> <0a6ad324-46f2-9270-5abd-dbc3e734cc8b@FreeBSD.org> <1515428308.44630.2.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1515428308.44630.2.camel@freebsd.org> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 16:29:44 -0000 On Mon, Jan 08, 2018 at 09:18:28AM -0700, Ian Lepore wrote: > 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... contigmalloc(M_WAITOK) isn't guaranteed to succeed either. In that case, M_WAITOK just means "try harder to defragment physical memory in the request space before giving up." > that's just a recipe for creating bugs.  It makes this whole function a bad > idea. A NULL return value from mallocarray() indicates a bug in the caller. I don't see why it isn't preferable to crash quickly and loudly in that case.