On 11/23/25 23:51, Pavel Begunkov wrote:
Add a file callback that maps a dmabuf for the given file and returns an opaque token of type struct dma_token representing the mapping.
I'm really scratching my head what you mean with that?
And why the heck would we need to pass a DMA-buf to a struct file?
Regards, Christian.
The implementation details are hidden from the caller, and the implementors are normally expected to extend the structure.
The callback callers will be able to pass the token with an IO request, which implemented in following patches as a new iterator type. The user should release the token once it's not needed by calling the provided release callback via appropriate helpers.
Signed-off-by: Pavel Begunkov asml.silence@gmail.com
include/linux/dma_token.h | 35 +++++++++++++++++++++++++++++++++++ include/linux/fs.h | 4 ++++ 2 files changed, 39 insertions(+) create mode 100644 include/linux/dma_token.h
diff --git a/include/linux/dma_token.h b/include/linux/dma_token.h new file mode 100644 index 000000000000..9194b34282c2 --- /dev/null +++ b/include/linux/dma_token.h @@ -0,0 +1,35 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _LINUX_DMA_TOKEN_H +#define _LINUX_DMA_TOKEN_H
+#include <linux/dma-buf.h>
+struct dma_token_params {
- struct dma_buf *dmabuf;
- enum dma_data_direction dir;
+};
+struct dma_token {
- void (*release)(struct dma_token *);
+};
+static inline void dma_token_release(struct dma_token *token) +{
- token->release(token);
+}
+static inline struct dma_token * +dma_token_create(struct file *file, struct dma_token_params *params) +{
- struct dma_token *res;
- if (!file->f_op->dma_map)
return ERR_PTR(-EOPNOTSUPP);- res = file->f_op->dma_map(file, params);
- WARN_ON_ONCE(!IS_ERR(res) && !res->release);
- return res;
+}
+#endif diff --git a/include/linux/fs.h b/include/linux/fs.h index c895146c1444..0ce9a53fabec 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -2262,6 +2262,8 @@ struct dir_context { struct iov_iter; struct io_uring_cmd; struct offset_ctx; +struct dma_token; +struct dma_token_params; typedef unsigned int __bitwise fop_flags_t; @@ -2309,6 +2311,8 @@ struct file_operations { int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *, unsigned int poll_flags); int (*mmap_prepare)(struct vm_area_desc *);
- struct dma_token *(*dma_map)(struct file *,
struct dma_token_params *);} __randomize_layout; /* Supports async buffered reads */
On Thu, Dec 04, 2025 at 11:46:45AM +0100, Christian König wrote:
On 11/23/25 23:51, Pavel Begunkov wrote:
Add a file callback that maps a dmabuf for the given file and returns an opaque token of type struct dma_token representing the mapping.
I'm really scratching my head what you mean with that?
And why the heck would we need to pass a DMA-buf to a struct file?
I find the naming pretty confusing a well. But what this does is to tell the file system/driver that it should expect a future read_iter/write_iter operation that takes data from / puts data into the dmabuf passed to this operation.
On 12/4/25 12:07, Christoph Hellwig wrote:
On Thu, Dec 04, 2025 at 11:46:45AM +0100, Christian König wrote:
On 11/23/25 23:51, Pavel Begunkov wrote:
Add a file callback that maps a dmabuf for the given file and returns an opaque token of type struct dma_token representing the mapping.
I'm really scratching my head what you mean with that?
And why the heck would we need to pass a DMA-buf to a struct file?
I find the naming pretty confusing a well. But what this does is to tell the file system/driver that it should expect a future read_iter/write_iter operation that takes data from / puts data into the dmabuf passed to this operation.
That explanation makes much more sense.
The remaining question is why does the underlying file system / driver needs to know that it will get addresses from a DMA-buf?
Regards, Christian.
On Thu, Dec 04, 2025 at 12:09:46PM +0100, Christian König wrote:
I find the naming pretty confusing a well. But what this does is to tell the file system/driver that it should expect a future read_iter/write_iter operation that takes data from / puts data into the dmabuf passed to this operation.
That explanation makes much more sense.
The remaining question is why does the underlying file system / driver needs to know that it will get addresses from a DMA-buf?
This eventually ends up calling dma_buf_dynamic_attach and provides a way to find the dma_buf_attachment later in the I/O path.
linaro-mm-sig@lists.linaro.org