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

[Shawn Webb]

On Fri, Jul 09, 2021 at 02:34:12PM -0600, Warner Losh wrote:
> 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?

That makes much more sense. Thanks a lot for the clarification!

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/dev-commits-src-all/attachments/20210709/ef846977/attachment.sig>