Date: Tue, 23 Jan 2018 18:04:02 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Bryan Drewery <bdrewery@FreeBSD.org>, cem@freebsd.org Cc: src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org 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/... Message-ID: <7d6e9800-d0d1-0855-6251-0ca46338acef@FreeBSD.org> In-Reply-To: <695a7cbd-f341-690c-5ad7-2551941bbf1e@FreeBSD.org> References: <201801211542.w0LFgbsp005980@repo.freebsd.org> <CAG6CVpXxuFyHS11rF=NF6bSSkC2=xnDh=WnbK-aWp4sOomrZ7w@mail.gmail.com> <51ff8aef-5660-7857-e4d5-12cdc77bc071@FreeBSD.org> <695a7cbd-f341-690c-5ad7-2551941bbf1e@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <pfg@freebsd.org> >>> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d6e9800-d0d1-0855-6251-0ca46338acef>