On 1/4/26 01:46, Ming Lei wrote:
On Sun, Nov 23, 2025 at 10:51:30PM +0000, Pavel Begunkov wrote:
Add an ability to register a dmabuf backed io_uring buffer. It also
needs know which device to use for attachment, for that it takes
target_fd and extracts the device through the new file op. Unlike normal
buffers, it also retains the target file so that any imports from
ineligible requests can be rejected in next patches.
Suggested-by: Vishal Verma <[email protected]>
Suggested-by: David Wei <[email protected]>
Signed-off-by: Pavel Begunkov <[email protected]>
---
...
+ dmabuf = dma_buf_get(rb->dmabuf_fd);
+ if (IS_ERR(dmabuf)) {
+ ret = PTR_ERR(dmabuf);
+ dmabuf = NULL;
+ goto err;
+ }
+
+ params.dmabuf = dmabuf;
+ params.dir = DMA_BIDIRECTIONAL;
+ token = dma_token_create(target_file, ¶ms);
+ if (IS_ERR(token)) {
+ ret = PTR_ERR(token);
+ goto err;
+ }
+
This way looks less flexible, for example, the same dma-buf may be used
on IOs to multiple disks, then it needs to be registered for each target
file.
It can probably be done without associating with a specific subsystem /
file on registration, but that has a runtime tracking cost; and I don't
think it's better. There is also a question of sharing b/w files when
it can be shared, e.g. files of the same filesystem, but I'm leaving it
for follow up work, it's not needed for nvme, and using one of the files
for registration should be reasonable.
--
Pavel Begunkov
