From owner-svn-src-all@freebsd.org Wed Jan 24 17:43:32 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10A14EB7CFA; Wed, 24 Jan 2018 17:43:32 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) (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 A0B8D6BC0C; Wed, 24 Jan 2018 17:43:31 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f41.google.com with SMTP id 68so6102186ite.4; Wed, 24 Jan 2018 09:43:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=Rtt9WA5DH5nD0WXtpDBSvrKYz08XA1LXvSkpKjkJG3Q=; b=NhedIop18WyDgHqlyktBNETgj2hQXW+ozhNczrnvs6l9gxRh+05SQQaB8I0e9RdV3X 8Gthd7iDAz1FqDVBzFw07TxQd44FtiYgzJ9CG69h0nAw3qE4C8NLz3eeM0vK0Uqxmj2e Da5uQW5awoxjBEOjq8+cQ4ZrtMYlpQq6D6Yzfhz6uC/AnIllmniWfc/kbq0QwepAsOgq 2Ssmypb3KXzQS0NqxO6BacpMgZObEfE+uiIfKFwYIOQPzlaRa6gOShZnHeDPYRrJyRfI XU9oWIlUJaWZHqy6or5GSKHLIhHQLV6ZgkqWPP3qIAC4Hnb2U8FHxuRmCmsmbZjQhpoG swMQ== X-Gm-Message-State: AKwxytcgGTXDjX9xSW2lKk2IdSAQ0KR8zn5sT6ES+H0RLghDl2Uz1YBh 4P1H9CTIxECkBfOK59T6aDiiPYLT X-Google-Smtp-Source: AH8x227ll/a7EZ2SAqlOlpXY2SJarqhex+/ofwSBRc069bbcggz+2F+QscIMgEaJcomO3cToMYdWzA== X-Received: by 10.36.90.137 with SMTP id v131mr9982250ita.41.1516815480462; Wed, 24 Jan 2018 09:38:00 -0800 (PST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id z197sm474109ioz.16.2018.01.24.09.38.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 09:38:00 -0800 (PST) Received: by mail-io0-f174.google.com with SMTP id z6so5647426iob.11; Wed, 24 Jan 2018 09:38:00 -0800 (PST) X-Received: by 10.107.15.89 with SMTP id x86mr9677978ioi.38.1516815479919; Wed, 24 Jan 2018 09:37:59 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.95.152 with HTTP; Wed, 24 Jan 2018 09:37:59 -0800 (PST) In-Reply-To: <51ff8aef-5660-7857-e4d5-12cdc77bc071@FreeBSD.org> References: <201801211542.w0LFgbsp005980@repo.freebsd.org> <51ff8aef-5660-7857-e4d5-12cdc77bc071@FreeBSD.org> From: Conrad Meyer Date: Wed, 24 Jan 2018 09:37:59 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev/... To: Pedro Giffuni Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" 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: Wed, 24 Jan 2018 17:43:32 -0000 On Tue, Jan 23, 2018 at 11:40 AM, Pedro Giffuni wrote: > On 23/01/2018 14:08, Conrad Meyer wrote: >> On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote: >>> >>> Author: pfg >>> Date: Sun Jan 21 15:42:36 2018 >>> New Revision: 328218 >> >> I'm confused about this change. Wouldn't it be better to remove the >> annotation/attributes from mallocarray() than to remove the protection >> against overflow? > > > Not in my opinion: it would be better to detect such overflows at compile > time (or through a static analyzer) than to have late notification though > panics. Sure, it would be better, but some situations are only detected at runtime -- hence mallocarray. And occasional use of the annotations on systems with plenty of RAM would keep the source tree free of compiler-detectable overflows, which I suspect are incredibly uncommon. > The blind use of mallocarray(9) is probably a mistake also: we > shouldn't use it unless there is some real risk of overflow. I'm not sure I follow that. >> (If the compiler is fixed in the future to not use >> excessive memory with these attributes, they can be conditionalized on >> compiler version, of course.) > > All in all, the compiler is not provably wrong: it's just using more swap > space, which is rather inconvenient for small platforms but not necessarily > wrong. Seems wrong if it's a noticeable amount. Maybe we could flip the annotations on or off with a low-ram build knob or something like that. Best, Conrad