From owner-freebsd-arch@freebsd.org Mon Feb 1 23:58:11 2016 Return-Path: Delivered-To: freebsd-arch@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 9DB27A98400 for ; Mon, 1 Feb 2016 23:58:11 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7DFC0F01 for ; Mon, 1 Feb 2016 23:58:11 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7C3BEA983FF; Mon, 1 Feb 2016 23:58:11 +0000 (UTC) Delivered-To: arch@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 61FD6A983FE for ; Mon, 1 Feb 2016 23:58:11 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (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 27603EFF for ; Mon, 1 Feb 2016 23:58:10 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-qg0-f48.google.com with SMTP id u30so117450qge.1 for ; Mon, 01 Feb 2016 15:58:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Rsi6PYpYTUqRsy5M8h+1cwm+aDsFud5jvScRXkwIPZs=; b=EowAesd1lwgl4S2Kb4zoU4KKPAQLLv6QMTWr0qXy9kDob3GZ/ckp9OInKFjKMohcBo hGlkKFRgEtcReJuW040fSr4YPucUwkK63XniWVAYhSNtPCXjDfxbQDSBPvfngQOU3kCu 4AtLspx+mKB4DBrSj+X5XeMiXmQXeaeI6vwsxuBycGOORCDOKz8/rS9EOHqoPEycpwis Aa+GLM3LI+BeN76EbybIMwyq+9X7/rZx/LJ/IkqeMFymJc3SSXJnAJU5pWAEzOiAdKgz 39AAg1IXquE3225adsmI8AOMPDjxik9+nQHB3cvkCOU5p6nm5Besfvupb6SEzYbHS7N3 gSuw== X-Gm-Message-State: AG10YOQytZ6u55Hy0EeoCcxwb8maihW8MHwSkB37IJiy0CZcHXUwPTUDivGXvRnWZrLr/w== X-Received: by 10.140.81.80 with SMTP id e74mr31505217qgd.27.1454365176888; Mon, 01 Feb 2016 14:19:36 -0800 (PST) Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com. [209.85.160.177]) by smtp.gmail.com with ESMTPSA id s64sm14993090qgd.28.2016.02.01.14.19.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Feb 2016 14:19:36 -0800 (PST) Received: by mail-yk0-f177.google.com with SMTP id z13so64837556ykd.0 for ; Mon, 01 Feb 2016 14:19:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.37.102.70 with SMTP id a67mr14640230ybc.89.1454365175883; Mon, 01 Feb 2016 14:19:35 -0800 (PST) Reply-To: cem@FreeBSD.org Received: by 10.37.4.23 with HTTP; Mon, 1 Feb 2016 14:19:35 -0800 (PST) In-Reply-To: <1EA0ECF5-D7AC-430E-957D-C4D49F9A872B@bsdimp.com> References: <20160201210256.GA29188@yamori.belopuhov.com> <1EA0ECF5-D7AC-430E-957D-C4D49F9A872B@bsdimp.com> Date: Mon, 1 Feb 2016 14:19:35 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: OpenBSD mallocarray From: Conrad Meyer To: Warner Losh Cc: Mike Belopuhov , "freebsd-arch@freebsd.org" , Ryan Stone Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 23:58:11 -0000 On Mon, Feb 1, 2016 at 1:12 PM, Warner Losh wrote: > >> On Feb 1, 2016, at 2:02 PM, Mike Belopuhov wrote: >> Not quite. From the man page: >> >> M_CANFAIL >> >> In the M_WAITOK case, if not enough memory is available, >> return NULL instead of calling panic(9). If mallocarray() >> detects an overflow or malloc() detects an excessive >> allocation, return NULL instead of calling panic(9). > > Yea, we don=E2=80=99t want it calling panic. Ever. That turns an overflow > into a DoS. I disagree. The panic is essentially an assertion that malloc was passed valid arguments. We have similar invariants assertions throughout the kernel and it is the only sane thing to do with overflow + M_WAITOK. M_WAITOK callers today will do something equally stupid if they get a NULL result from mallocarray(). > Arguments should be properly checked Yes! That's why the assertion is a good thing. > At best, CANFAIL is a kludge to fail with a panic instead of an > overflow. No, that's backwards. In CANFAIL mode, mallocarray returns NULL instead of panicing immediately. It's a kludge so the caller doesn't have to do overflow checking. > That=E2=80=99s got to be at most a transient thing until all the > code that it is kludged into with out proper thought is fixed. You mean the panic? What fallback behavior would you prefer? If the caller requested an overflowing allocation, there really isn't anything sane to do besides immediately panic (again, for M_WAITOK). Even M_NOWAIT callers may or may not do something sane. Best, Conrad