Date: Tue, 21 Jul 2026 17:38:52 -0400 From: Mark Johnston <markj@freebsd.org> To: Ryan Libby <rlibby@freebsd.org> Cc: Ed Maste <emaste@freebsd.org>, 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: <al_m7Jqjcs50QipP@nuc> In-Reply-To: <CAHgpiFwq_m3cS80e-WrBcftvE-M-1zb-0_9L6p5qD_vw139K8w@mail.gmail.com> References: <6a5fba36.3d93d.694b6c5c@gitrepo.freebsd.org> <CAHgpiFwq_m3cS80e-WrBcftvE-M-1zb-0_9L6p5qD_vw139K8w@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On Tue, Jul 21, 2026 at 11:57:41AM -0700, Ryan Libby wrote: > On Tue, Jul 21, 2026 at 11:28 AM Ed Maste <emaste@freebsd.org> wrote: > > > > The branch main has been updated by emaste: > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=caabdb3aefdc45cae90203210034086801fa9005 > > > > commit caabdb3aefdc45cae90203210034086801fa9005 > > Author: Ed Maste <emaste@FreeBSD.org> > > AuthorDate: 2026-07-21 18:10:00 +0000 > > Commit: Ed Maste <emaste@FreeBSD.org> > > 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 >home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?al_m7Jqjcs50QipP>