Date: Fri, 9 Jul 2021 14:34:12 -0600 From: Warner Losh <imp@bsdimp.com> To: Shawn Webb <shawn.webb@hardenedbsd.org> Cc: Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>, dev-commits-src-main@freebsd.org Subject: Re: git: 72821668b039 - main - stand/kmem_zalloc: panic when a M_WAITOK allocation fails Message-ID: <CANCZdfr4X%2Bjg5c1WrUWDMVDy9MmZMB%2Bp_%2BW09AKhNt7%2Bu1Fhxg@mail.gmail.com> In-Reply-To: <20210709195425.xzk2azaor4ielmb4@mutt-hbsd> References: <202107091726.169HQvGQ084473@gitrepo.freebsd.org> <20210709195425.xzk2azaor4ielmb4@mutt-hbsd>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 9, 2021 at 1:54 PM Shawn Webb <shawn.webb@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@FreeBSD.org> > > AuthorDate: 2021-07-09 17:21:18 +0000 > > Commit: Warner Losh <imp@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr4X%2Bjg5c1WrUWDMVDy9MmZMB%2Bp_%2BW09AKhNt7%2Bu1Fhxg>