bus_dmamap_sync() for bounced client buffers from user address space

[John Baldwin]

On Tuesday, April 28, 2015 12:10:43 PM Adrian Chadd wrote:
> On 28 April 2015 at 09:19, Warner Losh <imp at bsdimp.com> wrote:
> >
> >> On Apr 28, 2015, at 7:40 AM, John Baldwin <jhb at FreeBSD.org> wrote:
> >>
> >>> 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.
> >
> > Fusion I/O’s SDK used this trick to allow mapping of userspace buffers down
> > into the block layer after doing the requisite locking / pinning / etc of the buffers
> > into memory. That’s if memory serves correctly (the SDK did these things, I can’t
> > easily check on that detail since I’m no longer at FIO).
> 
> This is a long-standing trick. physio() does it too,
> aio_read/aio_write does it for direct block accesses. Now that pbufs
> aren't involved anymore, it should scale rather well.
> 
> So I'd like to see more of it in the kernel and disk/net APIs and drivers.

aio_read/write jump through gross hacks to create dedicated kthreads that
"borrow" the address space of the requester.  The fact is that we want to
make unmapped I/O work in the general case and the same solutions for
temporary mappings for that can be reused to temporarily map the wired
pages backing a user request when needed.  Reusing user mappings directly
in the kernel isn't really the way forward.

-- 
John Baldwin