[PATCH] RFC: dma-buf: userspace mmap support

[Tom Cooksey]

> -----Original Message-----
> From: Alan Cox [mailto:alan at lxorguk.ukuu.org.uk]
> Sent: 17 March 2012 20:17
> To: Tom Cooksey
> Cc: 'Rob Clark'; linaro-mm-sig at lists.linaro.org; dri-
> devel at lists.freedesktop.org; linux-media at vger.kernel.org;
> rschultz at google.com; Rob Clark; sumit.semwal at linaro.org;
> patches at linaro.org
> Subject: Re: [PATCH] RFC: dma-buf: userspace mmap support
> 
> > > dma-buf file descriptor.  Userspace access to the buffer should be
> > > bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to
> > > give the exporting driver a chance to deal with cache
> synchronization
> > > and such for cached userspace mappings without resorting to page
> 
> There should be flags indicating if this is necessary. We don't want
> extra
> syscalls on hardware that doesn't need it. The other question is what
> info is needed as you may only want to poke a few pages out of cache
> and
> the prepare/finish on its own gives no info.
> 
> > E.g. If another device was writing to the buffer, the prepare ioctl
> > could block until that device had finished accessing that buffer.
> 
> How do you avoid deadlocks on this ? We need very clear ways to ensure
> things always complete in some form given multiple buffer
> owner/requestors and the fact this API has no "prepare-multiple-
> buffers"
> support.

Yes, good point.

If the API was to also be used for synchronization it would have to
include an atomic "prepare multiple" ioctl which blocked until all
the buffers listed by the application were available. In the same
way, the kernel interface would also need to allow drivers to pass a
list of buffers a job will access in an atomic "add job" operation.
Actually, our current "KDS" (Kernel Dependency System) implementation
already works like this.

This might be a good argument for keeping synchronization and cache
maintenance separate, though even ignoring synchronization I would
think being able to issue cache maintenance operations for multiple
buffers in a single ioctl might present some small efficiency gains.
However as Rob points out, CPU access is already in slow/legacy
territory.

Note: Making the ioctl a "prepare multiple" would at least prevent
accidental dead-locks due to cross-dependencies, etc., but I think
some kind of watchdog/timeout would be useful on userspace locks to
stop a malicious application from preventing other devices and
processes from using buffers indefinitely.

Finally, it's probably worth mentioning that when we implemented
KDS we differentiated jobs which needed "exclusive access" to a
buffer and jobs which needed "shared access" to a buffer. Multiple
jobs could access a buffer at the same time if those jobs all
indicated they only needed shared access. Typically this would be
ajob which will only read a buffer, such as a display controller
or texture read. The main use-case for this was implementing EGL's
preserved swap behaviour when using "buffer flipping". Here, the
display controller will be reading the front buffer, but the GPU
might also need to read that front buffer. So perhaps adding
"read-only" & "read-write" access flags to prepare could also be
interpreted as shared & exclusive accesses, if we went down this
route for synchronization that is. :-)


Cheers,

Tom