On Fri, Jul 9, 2021 at 1:54 PM Shawn Webb <[email protected]> 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 <[email protected]> > > AuthorDate: 2021-07-09 17:21:18 +0000 > > Commit: Warner Losh <[email protected]> > > 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 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all To unsubscribe, send any mail to "[email protected]"
