OpenBSD mallocarray
Conrad Meyer
cem at FreeBSD.org
Mon Feb 1 23:58:11 UTC 2016
On Mon, Feb 1, 2016 at 1:12 PM, Warner Losh <imp at bsdimp.com> wrote:
>
>> On Feb 1, 2016, at 2:02 PM, Mike Belopuhov <mike at belopuhov.com> 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’t 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’s 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
More information about the freebsd-arch
mailing list