From owner-svn-src-all@freebsd.org Tue Jan 23 23:12:01 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 67F39ECE60E for ; Tue, 23 Jan 2018 23:12:01 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from sonic305-18.consmr.mail.bf2.yahoo.com (sonic305-18.consmr.mail.bf2.yahoo.com [74.6.133.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B589968354 for ; Tue, 23 Jan 2018 23:04:08 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1516748647; bh=LmFz27SAAKflJikPbdcP4BapGkVKhMIoEh+qaHJtXFc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=QS7h4YcKndMlwScr19TJwop6WQ8vvNKatBqhiMgydWlLqpyUbjYIfh3KhVxB6hgbcT06FcSkiZMWIwup6Sl1906cBkZBlj71al4jmKar3p4vhITBfIoNyxSNvWHO7Sdsl5RyP2d6iaxDaiVhH94V+j7vSJNYNkhcfX1BkPIyn3pWi+XEFdijFhLAtIPCdpOQk6c7MHxvcAI2lpaw5ti6FMhbH/WLJ7fh3JhCprv67ahp09yxAmqHukygqj5n5niRa/F7n+/EUeSOGmxBFkacy8qPjV1CiA1/X5imvFaEV6DKnJ/5d+BCRilaYEF/Oj/D0HUhH2VvCdW1taYC/0aJZQ== X-YMail-OSG: DC.Jof4VM1lLrW4p6gZHn0WX20j4qVlkP8_XH5SVN69itNwpL99wjExpQXR.IUL PbIHizNLYrgqZIxtNwxlotc6tzRyBH1syq_xDM4kCgJ6Ry.xLgHjr.9MY4wbiwNglxlpwIE1spgO hDkYs9fDSAOfinBpxZtzJLQClvgxPAYsHnOwRoLmdq8.lUP4OIsNiDb20a44fEAMsYDs2l7IRAKP E8Z4gizUVH_YhFdU.7r8IzdxuOmPqtuLQaYsyCymrDWmQw5Y3GLUtHgiI0b.GZhCJpQknaU6hYr4 P_JKYYeTnMkKoVla9d1peVeU2_lDat9r1zi21CdtyLARJHsDxejWQXHpqz.f0iGalanzx5xzW2Mx K33mVJ10imx514rV8OBhN1ssuQmJpEbiUbA.Ye8bRP1.UFEra9SVrRoPpXB9Xs5DiC9CUCjzxmjk OJcokfSbpdEal8FKGaddZe9UuRumy5aX4hFX.qNn4OaC3UJ8gs5lGOSXb0u5WWE7z7ynujlfF.MT CAl5W2F2Chg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Tue, 23 Jan 2018 23:04:07 +0000 Received: from smtp103.rhel.mail.bf1.yahoo.com (EHLO [192.168.0.8]) ([98.139.230.213]) by smtp413.mail.bf1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 3e101f6fcb5385e598f3190fe37a2d27; Tue, 23 Jan 2018 23:04:04 +0000 (UTC) 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: Bryan Drewery , cem@freebsd.org Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201801211542.w0LFgbsp005980@repo.freebsd.org> <51ff8aef-5660-7857-e4d5-12cdc77bc071@FreeBSD.org> <695a7cbd-f341-690c-5ad7-2551941bbf1e@FreeBSD.org> From: Pedro Giffuni Organization: FreeBSD Project Message-ID: <7d6e9800-d0d1-0855-6251-0ca46338acef@FreeBSD.org> Date: Tue, 23 Jan 2018 18:04:02 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <695a7cbd-f341-690c-5ad7-2551941bbf1e@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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: Tue, 23 Jan 2018 23:12:01 -0000 Hi; On 23/01/2018 17:13, Bryan Drewery wrote: > On 1/23/2018 11:40 AM, Pedro Giffuni wrote: >> Hi; >> >> >> On 23/01/2018 14:08, Conrad Meyer wrote: >>> Hi Pedro, >>> >>> 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 >>>> URL: https://svnweb.freebsd.org/changeset/base/328218 >>>> >>>> Log: >>>>    Revert r327828, r327949, r327953, r328016-r328026, r328041: >>>>    Uses of mallocarray(9). >>>> >>>>    The use of mallocarray(9) has rocketed the required swap to build >>>> FreeBSD. >>>>    This is likely caused by the allocation size attributes which put >>>> extra pressure >>>>    on the compiler. >>> 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. The blind use of mallocarray(9) is probably >> a mistake also: we shouldn't use it unless there is some real risk of >> overflow. >> >>>    (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. >> >> Pedro. >> >> > I haven't dug into this to understand it all, but if mallocarray() is > causing this sort of compilation problem then isn't the problem the > compiler? Why keep a "dangerous" function around and not actually fix > it? Is there a bug somewhere to fix the compilation load? > In all honesty .. I don't know what is going on. I theorize it may be related to attributes but who knows. I wouldn't say mallocarray(9) is dangerous, it's just not worth my time specially since most of those multiplications have no chance of overflowing. I will put up a patch with all the malloc --> mallocarray replacements in case someone wants to spend time on it. Pedro.