From nobody Tue Jul 21 21:38:52 2026 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4h4W3f68BWz6mVDP; Tue, 21 Jul 2026 21:38:54 +0000 (UTC) (envelope-from markj@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "YR1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4h4W3f5Qwmz3cHp; Tue, 21 Jul 2026 21:38:54 +0000 (UTC) (envelope-from markj@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1784669934; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8SBJ1n1VIS1vLIdWhgC5WQCGJBA+GglFGtl7uckrGpc=; b=kYe3mwuYFbcdjk7nF98GPKZsC/WJs12nM83hTcebEFF8NnPEGjcA3uBBv/kqHgj0LcSJap nK6tk16nvI8x0Mij/w0Y65cSqlmDZmx4koCw9GAJA8+33oA4QNCEAKZfb/aY4rvasFNQas xZqJZ/2vwXfvuQqlXMCfdxOaHDTOeT+QQZkdEbvJwDuVKeSPPOyw2SXHP/TflU4H1JrJPC tyak5OwNXUmJcHCEdyfTMVUyXRuWlK+sKVirhi4T0PuURuOlWPR9O7O+I3ABPOzUBmyL0q lcIhtOaE+/nDuhjjThZv9QoCl2nUmp8+CMuMlKgPF9kIFWzr3rXMvTxKGP2OkQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1784669934; a=rsa-sha256; cv=none; b=QuUQCRpGaTfwMx7j97sL/3fHJgMxYpuvJNU8Rgsre/DJ2vUgOHibLjbo829yzLbCiVgZW8 bwYxMTPakSmzQA5cK4pZao8au9C9Ft2ykVpwF0V4XknSTF57a2wNQ9bfceMI7YHLQNCIaD JCmX8Eliav3sWvU8h87VVXISyG29v0Qi8bmoVK3vZalvNJWkMqX+ijZvlzeYlutcFZClGL /oUjdAFlvDEfyyNVTRp17lhl06MRGSHCzJf04LhPB0iKlw2RLLP+cDjb8K3cXius106jms mY3idnF6lRpiV0lhQApA8Gh55ImQ5p7z+BD6N/kG2vVdu7NfjRm76GY0ymC1qQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1784669934; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8SBJ1n1VIS1vLIdWhgC5WQCGJBA+GglFGtl7uckrGpc=; b=pM7gg2iQl/hm5n25liRQN02dQQodgA+V/xv0/UbWfSEeatGH8Op0adIBgLDhgQ/dL7uGqJ g8NE3GRqvgiRyBEcFDSec9mqh/2RZ5OIff/LuBqKGgp9/mwP1avllE4cOrympWB/boj9Vu VvU6gi1qcJs/7T7LZ4zjtMP/Kc1+hfCKVwrqtNUc4lldxNMkZzM0sWkB9EGthhkKclvbrc bOM0toqnRGtwU8Dk5J3VxypQ6+nuvS0tMtawfflNBGOk82eX7psWMtW4wkGFe4BwEJm2z6 uC5uf6lojin/aluAD6Md0m3zzUV6hxHl1qWGfi1ehAeROQ0QfCiFRmQvW6p/lw== Received: from nuc (192-0-220-237.cpe.teksavvy.com [192.0.220.237]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: markj) by smtp.freebsd.org (Postfix) with ESMTPSA id 4h4W3f2XBFzQGt; Tue, 21 Jul 2026 21:38:54 +0000 (UTC) (envelope-from markj@freebsd.org) Date: Tue, 21 Jul 2026 17:38:52 -0400 From: Mark Johnston To: Ryan Libby Cc: Ed Maste , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: caabdb3aefdc - main - contigmalloc.9: Note that M_WAITOK may still return NULL Message-ID: References: <6a5fba36.3d93d.694b6c5c@gitrepo.freebsd.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Jul 21, 2026 at 11:57:41AM -0700, Ryan Libby wrote: > On Tue, Jul 21, 2026 at 11:28 AM Ed Maste wrote: > > > > The branch main has been updated by emaste: > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=caabdb3aefdc45cae90203210034086801fa9005 > > > > commit caabdb3aefdc45cae90203210034086801fa9005 > > Author: Ed Maste > > AuthorDate: 2026-07-21 18:10:00 +0000 > > Commit: Ed Maste > > CommitDate: 2026-07-21 18:27:47 +0000 > > > > contigmalloc.9: Note that M_WAITOK may still return NULL > > > > Reviewed by: markj, bapt > > Sponsored by: The FreeBSD Foundation > > Differential Revision: https://reviews.freebsd.org/D58382 > > --- > > share/man/man9/contigmalloc.9 | 11 ++++++++++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/share/man/man9/contigmalloc.9 b/share/man/man9/contigmalloc.9 > > index 2e5d55ae8ba1..a9ebaf100eb9 100644 > > --- a/share/man/man9/contigmalloc.9 > > +++ b/share/man/man9/contigmalloc.9 > > @@ -23,7 +23,7 @@ > > .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > > .\" POSSIBILITY OF SUCH DAMAGE. > > .\" > > -.Dd July 26, 2024 > > +.Dd July 21, 2026 > > .Dt CONTIGMALLOC 9 > > .Os > > .Sh NAME > > @@ -124,6 +124,15 @@ function returns a kernel virtual address if allocation succeeds, > > or > > .Dv NULL > > otherwise. > > +Note that in contrast with > > +.Xr malloc 9 , > > +.Fn contigmalloc > > +may return > > +.Dv NULL > > +even if > > +.Dv M_WAITOK > > +is specified, if no physically congiguous range is available that meets the > > +specified constraints. > > .Sh EXAMPLES > > .Bd -literal > > void *p; > > > > But is this desired and intentional behavior, or simply what the code does? I think this is intentional and a natural consequence of the interface. It may simply be impossible for contigmalloc() to satisfy the request if there is no free physical memory available in the specified paddr range, in which case it seems better to return NULL than to loop forever. That said, I think the claim in the man page is actually wrong now. contigmalloc(M_WAITOK) certainly used to be able to return NULL, but I think that might no longer be true now that kmem_alloc_contig() is implemented using domainset iterators. If we try all domains, we'll end up sleeping and retrying indefinitely, or at least it appears to be that way. > Paging through grep of contigmalloc with M_WAITOK, it appears to be a > mix of callers that handle and do not handle a NULL return. Some of > them just handle it by panicking. Is someone planning to audit > M_WAITOK callers? > > > +is specified, if no physically congiguous range is available that meets the > > Typo: "congiguous". > > Ryan >