Date: Tue, 14 Aug 2001 14:56:53 -0700 (PDT) From: Bill Paul <wpaul@FreeBSD.org> To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/alpha/alpha busdma_machdep.c Message-ID: <200108142156.f7ELurE44643@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
wpaul 2001/08/14 14:56:53 PDT
Modified files:
sys/alpha/alpha busdma_machdep.c
Log:
Fix yet another "unconditionally free()ing memory without even checking
to see if it was malloc()ed first" bug. In bus_dmamap_create(), one of
two things can happen: either we need to allocate a special map due to
some manner of bounce buffering requirement, or we can DMA a buffer
in place. On the x86 platform, the "in place" case results in
bus_dmamap_create() returning a dmamap of NULL. The bus_dmamap_destroy()
routine later checks for NULL and won't bother free()ing the map if
it detects this condition.
But on the alpha, we don't use NULL, we use a statically allocated map
called nobounce_dmamap(). Unfortunately, bus_dmamap_destroy() does not
handle the condition where we attempt to destroy such a map: it tries
to free() the dmamap, which causes a panic.
Fix: test that map != &nobounce_dmamap before trying to free() it.
With this fix, my busdma-ified if_sis driver works on the alpha. I'm
a bit alarmed that I'm the first person ever to trip over this bug, since
we have been using busdma on the alpha for a while, and since it sort
of screams out "Hi! I'm a bug! Booga-booga!" when you look at it.
(Somewhere, somebody will say: "But Bill, why don't you just not bother
destroying the maps in this case." Because the API is supposed to be
a) symetrical and b) opaque to the caller. I can't know whether it's safe
to skip the bus_dmamap_destroy() step or not without sticking my fingers
into unsafe places, which is what I wanted to avoid in the first place.)
Revision Changes Path
1.19 +8 -2 src/sys/alpha/alpha/busdma_machdep.c
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108142156.f7ELurE44643>