From owner-dev-commits-src-all@freebsd.org Fri Jul 9 20:34:25 2021 Return-Path: Delivered-To: dev-commits-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E240C6660EA for ; Fri, 9 Jul 2021 20:34:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GM4dY5cQ3z3JRW for ; Fri, 9 Jul 2021 20:34:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x830.google.com with SMTP id c9so4454047qte.6 for ; Fri, 09 Jul 2021 13:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dqPoCulu499GOXS7I1BI3tFTyc/v6/IzhGnfpiTpAEo=; b=K5rnQgkFSaRY68QX4c2wzNWKQF+rf+pLwLzrAyX1affrdaBtf3ofWhN2XJzgXSiIXJ QXE/j14W/Fos22dHp+Fg+bLnCdTTrbr0ldVtk5VQMp1keM64zPauSwMhnjWFEQAZbglh 1qXUOk5xe+Ca+2nikEf6oioxqSyUh4mJSt+vAo2L+pEqB5HAdmJg5LRB6zPs8juBdgL6 6pnODUMlxZfpv8v1FB4fqnfO/6vWGkBt9cf683mcatGsRnoFCrJbpWWHt1Ygt8Qer7kN 2B3c/eEHjX5uuclVh2hNkDPVoWGB1jjjN7UzNVnt2NSHTmGPbOooCIoU4J5dlRiFvoAN ebdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dqPoCulu499GOXS7I1BI3tFTyc/v6/IzhGnfpiTpAEo=; b=ZEsXvjp0mEZzqVcSoTBF/SFygSCaOBz/CRmcguyDrizNmSdSXRGR4gvZ1IYL+KsWT2 OKAOM+yF6Y9rWgP3k4ANG2FZd59CjkEdqpDZbcHUqj9xc4XtVC13BXuBQSx4oJlymtf2 XRA2REAFAsAfAquUvSlzuWRnlBpWvna1ECHV/PTRKl906ch0ZPOP1NOf2GTZrcf6OwLR X+XDHGufyEbRP1+OqTsZK61bpym5CqIXgrFe9dVlUOrM0SOvspgifSEU5pRwrhszMAxb jP2B2jaIbKsoXPofXBxjvyWM0q8BpRrcDbFrVuVgEwscgxxEbNZnjQDn3uHXV7HhFrJq 4sdw== X-Gm-Message-State: AOAM530wpc6Kyb/89v0yNc9JhWh0M2dGOZ8vgsWFK2PFySDndJZgs2JW mnZcnXX1On1nGWH7/lrO0fjkXlcb+JSL+gsnXjkIfg== X-Google-Smtp-Source: ABdhPJytaDHZKCZVmivilBF8V8wxh5TdKen4IqRB554rcVUFsDk6pSLtb8GYpNwIkgmSas9fHyanT+H+V4sJXbq3giE= X-Received: by 2002:ac8:5314:: with SMTP id t20mr2982637qtn.235.1625862864517; Fri, 09 Jul 2021 13:34:24 -0700 (PDT) MIME-Version: 1.0 References: <202107091726.169HQvGQ084473@gitrepo.freebsd.org> <20210709195425.xzk2azaor4ielmb4@mutt-hbsd> In-Reply-To: <20210709195425.xzk2azaor4ielmb4@mutt-hbsd> From: Warner Losh Date: Fri, 9 Jul 2021 14:34:12 -0600 Message-ID: Subject: Re: git: 72821668b039 - main - stand/kmem_zalloc: panic when a M_WAITOK allocation fails To: Shawn Webb Cc: Warner Losh , src-committers , "" , dev-commits-src-main@freebsd.org X-Rspamd-Queue-Id: 4GM4dY5cQ3z3JRW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: dev-commits-src-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the src repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 20:34:25 -0000 On Fri, Jul 9, 2021 at 1:54 PM Shawn Webb 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 > > AuthorDate: 2021-07-09 17:21:18 +0000 > > Commit: Warner Losh > > 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