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/...

Warner Losh imp at bsdimp.com
Wed Jan 24 21:13:34 UTC 2018


On Wed, Jan 24, 2018 at 12:40 PM, Conrad Meyer <cem at freebsd.org> wrote:

> On Wed, Jan 24, 2018 at 11:27 AM, Warner Losh <imp at bsdimp.com> wrote:
> >
> > Which is why we should add check overflows for most of the no wait cases.
> > They should be checked, but not primarily with mallocarray...
>
> I don't understand what the distinction is here.  Can you help me
> understand why the overflow check should be lifted from mallocarray
> into the caller for no wait cases?  Or is that not what you're
> suggesting?
>

mallocarray should be the last line of defense, not the only line of
defense.

most of the time, it's more correct to say

if (WOULD_OVERFLOW(a,b))
    return EINVAL;
ptr = mallocarray(a,b...);

since an error return, assuming it's handled correctly is preferable to a
panic.

I thought this was more true for NOWAIT than for WAITOK cases, but I've
realized it's more true always.

And that's why I have such a problem with mallocarray: it's only useful
when people are lazy and haven't checked, and then it creates a DoS path
for things that don't check. We'll change it now and think we're safe, when
we still have issues, just different issues than before. It may be a
necessary change, but it certainly isn't sufficient.

Warner


More information about the svn-src-all mailing list