svn commit: r266775 - head/sys/x86/x86

John Baldwin jhb at freebsd.org
Fri May 30 15:47:52 UTC 2014


On Friday, May 30, 2014 11:39:24 am Attilio Rao wrote:
> On Fri, May 30, 2014 at 5:03 PM, John Baldwin <jhb at freebsd.org> wrote:
> > On Friday, May 30, 2014 10:54:06 am Attilio Rao wrote:
> >> On Tue, May 27, 2014 at 11:31 PM, Scott Long <scottl at freebsd.org> wrote:
> >> > Author: scottl
> >> > Date: Tue May 27 21:31:11 2014
> >> > New Revision: 266775
> >> > URL: http://svnweb.freebsd.org/changeset/base/266775
> >> >
> >> > Log:
> >> >   Eliminate the fake contig_dmamap and replace it with a new flag,
> >> >   BUS_DMA_KMEM_ALLOC.  They serve the same purpose, but using the flag
> >> >   means that the map can be NULL again, which in turn enables significant
> >> >   optimizations for the common case of no bouncing.
> >>
> >> While I think this is in general a good idea, unfortunately our
> >> drivers do so many dumb things when freeing DMA allocated buffers that
> >> having a NULL map is going to cause some "turbolence" and make such
> >> bugs more visible.
> >> An example is with ATA, where I think this fix is needed:
> >> http://www.freebsd.org/~attilio/dmamem_free-ata.patch
> >>
> >> Otherwise, what can happen with bounce buffers, is that the allocated
> >> memory via contig malloc was not going to be freed anytime.
> >>
> >> I tried to look around and I found questionable (read broken) code in
> >> basically every driver which allocates DMA buffers, so I really don't
> >> feel I want to fix the majority of our drivers. I just think such
> >> paths are not excercised enough to be seen in practice often or the
> >> bugs just get unnoticed.
> >
> > Eh, many maps for static allocations were already NULL and have been for a
> > long time.  This is nothign new.  Plus, the diff you posted has a bug
> > regardless of explicitly destroying a map created by bus_dmamem_alloc().
> 
> Did you notice that I *removed* the destroy not *added*?

Yes, my point was that that bug in the original code you are fixing was there
regardless of Scott's change.

-- 
John Baldwin


More information about the svn-src-head mailing list