Can this be called with a NULL map? Hmm, I guess it can. FWIW, x86 handles this in the header file so the check gets inlined sooner in sys/kern/subr_busdma_bounce.c. That is, x86 checks it in sys/x86/include/bus_dma.h:_bus_dmamap_waitok(). Presumably could do the same here?

Great idea.. Just implemented it. Thank you!

Couldn't this be merged into the if above? In the else case we return an error if *mapp == NULL.

Could we get here with buf being misaligned for the dma tag? If so it looks like might_bounce could return true so we write to nobounce_dmamap leading to a race.

Good catch. I think the fix is to restrict map elision to coherent tags that accept any alignment. Thank you!

Actually, this is not possible. When eliding the map, we check dmat->bounce_flags & (BF_COULD_BOUNCE | BF_COHERENT | BF_FORCE_MAP)) == BF_COHERENT , and BF_COULD_BOUNCE is set in bounce_bus_dma_tag_create() on tags with alignment > 1 or that cannot map all of memory.

This else is unneeded. Everything to the out label are now part of the else

In that case would doing something like this here be useful? It lets us skip the might_bounce check & most of the while loop:

if (!_bus_dmamap_addsegs(dmat, map, curaddr, sgsize, segs, segp))
	bus_dmamap_unload(dmat, map);
	return (EFBIG); /* XXX better return value here? */
}
return (0);

We could also insert the call to _bus_dmamap_addsegs here & return.

I don't think that works here. It works in load_phys because the addr is phys contig. Here we have a virtual addr which might not be phys contig, and we need the pmap_extract() below to do virt->phys.