git: 72821668b039 - main - stand/kmem_zalloc: panic when a M_WAITOK allocation fails

Warner Losh imp at bsdimp.com
Fri Jul 9 20:34:26 UTC 2021


On Fri, Jul 9, 2021 at 1:54 PM Shawn Webb <shawn.webb at hardenedbsd.org>
wrote:

> On Fri, Jul 09, 2021 at 05:26:57PM +0000, Warner Losh wrote:
> > The branch main has been updated by imp:
> >
> > URL:
> https://cgit.FreeBSD.org/src/commit/?id=72821668b039c276914569e9caa1cdfa4e4cb674
> >
> > commit 72821668b039c276914569e9caa1cdfa4e4cb674
> > Author:     Warner Losh <imp at FreeBSD.org>
> > AuthorDate: 2021-07-09 17:21:18 +0000
> > Commit:     Warner Losh <imp at FreeBSD.org>
> > CommitDate: 2021-07-09 17:21:18 +0000
> >
> >     stand/kmem_zalloc: panic when a M_WAITOK allocation fails
> >
> >     Malloc() might return NULL, in which case we will panic with a NULL
> >     pointer deref. Make it panic when the allocation fails to preserve
> the
> >     postcondtion that we never return a non-NULL value.
>
> malloc(9) tells us that M_WAITOK will never fail. I'm thinking this
> conditional might need to be negated for the !M_WAITOK case, in which
> malloc(9) could indeed fail.
>
> Although, even as I type this email, I just realized that a different
> function, Malloc, is being called. What's the difference between
> malloc and Malloc?
>

The block of code is to be used in the standalone environment.
The Malloc() function there doesn't have wait/nowait variants and
can fail (though in the boot loader, that almost never happens except
 when there's a bug). The code is for wrappers around kmem_zalloc
which is the OpenZFS spelling of malloc. It assumes that kmem_zalloc
with M_WAITOK will never return NULL, so it never checks. This
changes a weird panic when the returned NULL pointer is dereferenced,
to an orderly panic when the malloc that the code assumes will never
fail actuall fails. This at least gives better context of where the error
happened and what the error was. In practice, this is a big nop, but
we have had issues with other Malloc calls in the past failing because
of bugs that caused us to ask for a ridiculous amount of memory.

Make sense?

Warner


More information about the dev-commits-src-main mailing list