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

[John Baldwin]

On Friday, May 30, 2014 12:55:06 pm Attilio Rao wrote:
> On Fri, May 30, 2014 at 6:44 PM, John Baldwin <jhb at freebsd.org> wrote:
> > On Friday, May 30, 2014 11:51:38 am Attilio Rao wrote:
> >> On Fri, May 30, 2014 at 5:47 PM, John Baldwin <jhb at freebsd.org> wrote:
> >> > 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.
> >>
> >> And when I did say something different?
> >> I don't understand what's the point of your messages, besides showing
> >> that you didn't read correctly my patch.
> >
> > I read yours correctly but worded mine poorly.  My point is that Scott's
> > change does not introduce anything new.  We've had NULL maps for static
> > allocations for many, many years.  It's only been recently that we've
> > had more maps not be NULL for this.  However, even if you discounted
> > the whole NULL vs non-NULL maps thing, the driver in question that you
> > are fixing was broken regardless.  That is, due to the extra
> > bus_dmamap_destroy() the driver was broken regardless of whether the map
> > was NULL or non-NULL.
> 
> To be honest, pre-266775 the kernel would actually panic for this
> specific driver, because we were going to free memory that was never
> allocated (by having a valid mapping but an invalid dma memory
> pointer).

pre-239354 bus_dma would have used a NULL map just as it does now.  And
even some allocations during that window could still use a NULL map.  The
idea of a NULL map is not a new concept.  Most maps from bus_dmamem_alloc()
have been NULL for most of bus_dma's existence.

> That was prompted to look at the dma_alloc_*() bits of drivers.
> We need to make a real sweep at drivers on these bits.

I did a start: http://p4web.freebsd.org/@@1194266?ac=10

-- 
John Baldwin