bus_dmamap_sync() for bounced client buffers from user address space

[John Baldwin]

On Saturday, April 25, 2015 07:34:44 PM Konstantin Belousov wrote:
> On Sat, Apr 25, 2015 at 09:02:12AM -0500, Jason Harmening wrote:
> > It seems like in general it is too hard for drivers using busdma to deal
> > with usermode memory in a way that's both safe and efficient:
> > --bus_dmamap_load_uio + UIO_USERSPACE is apparently really unsafe
> > --if they do things the other way and allocate in the kernel, then then
> > they better either be willing to do extra copying, or create and
> > refcount their own vm_objects and use d_mmap_single (I still haven't
> > seen a good example of that), or leak a bunch of memory (if they use
> > d_mmap), because the old device pager is also really unsafe.
> munmap(2) does not free the pages, it removes the mapping and dereferences
> the backing vm object.  If the region was wired, munmap would decrement
> the wiring count for the pages.  So if a kernel code wired the regions
> pages, they are kept wired, but no longer mapped into the userspace.
> So bcopy() still does not work.
> 
> d_mmap_single() is used by GPU, definitely by GEM and TTM code, and possibly
> by the proprietary nvidia driver.

Yes, the nvidia driver uses it.  I've also used it for some proprietary
driver extensions.

> I believe UIO_USERSPACE is almost unused, it might be there for some
> obscure (and buggy) driver.

I believe it was added (and only ever used) in crypto drivers, and that they
all did bus_dma operations in the context of the thread that passed in the
uio.  I definitely think it is fragile and should be replaced with something
more reliable.

-- 
John Baldwin