0959a1683d
- Again move the information relevant for driver writers next to the callbacks. - Put the overview and userspace interface documentation into a DOC: section within the code. - Remove the text that mmap needs to be coherent - since the DMA_BUF_IOCTL_SYNC landed that's no longer the case. But keep the text that for pte zapping exporters need to adjust the address space. - Add a FIXME that kmap and the new begin/end stuff used by the SYNC ioctl don't really mix correctly. That's something I just realized while doing this doc rework. - Augment function and structure docs like usual. Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> [sumits: fix cosmetic issues] Link: http://patchwork.freedesktop.org/patch/msgid/20161209185309.1682-5-daniel.vetter@ffwll.ch
48 lines
2.0 KiB
Plaintext
48 lines
2.0 KiB
Plaintext
DMA Buffer Sharing API Guide
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sumit Semwal
|
|
<sumit dot semwal at linaro dot org>
|
|
<sumit dot semwal at ti dot com>
|
|
|
|
|
|
Other Interfaces Exposed to Userspace on the dma-buf FD
|
|
------------------------------------------------------
|
|
|
|
- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only
|
|
with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow
|
|
the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other
|
|
llseek operation will report -EINVAL.
|
|
|
|
If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all
|
|
cases. Userspace can use this to detect support for discovering the dma-buf
|
|
size using llseek.
|
|
|
|
Miscellaneous notes
|
|
-------------------
|
|
|
|
- Any exporters or users of the dma-buf buffer sharing framework must have
|
|
a 'select DMA_SHARED_BUFFER' in their respective Kconfigs.
|
|
|
|
- In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set
|
|
on the file descriptor. This is not just a resource leak, but a
|
|
potential security hole. It could give the newly exec'd application
|
|
access to buffers, via the leaked fd, to which it should otherwise
|
|
not be permitted access.
|
|
|
|
The problem with doing this via a separate fcntl() call, versus doing it
|
|
atomically when the fd is created, is that this is inherently racy in a
|
|
multi-threaded app[3]. The issue is made worse when it is library code
|
|
opening/creating the file descriptor, as the application may not even be
|
|
aware of the fd's.
|
|
|
|
To avoid this problem, userspace must have a way to request O_CLOEXEC
|
|
flag be set when the dma-buf fd is created. So any API provided by
|
|
the exporting driver to create a dmabuf fd must provide a way to let
|
|
userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd().
|
|
|
|
References:
|
|
[1] struct dma_buf_ops in include/linux/dma-buf.h
|
|
[2] All interfaces mentioned above defined in include/linux/dma-buf.h
|
|
[3] https://lwn.net/Articles/236486/
|