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/...
Pedro Giffuni
pfg at FreeBSD.org
Tue Jan 23 23:12:01 UTC 2018
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 at 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.
More information about the svn-src-all
mailing list