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