Re: [PATCH] nvme/io_uring: enable dma-buf backed passthrough I/O

[Pavel Begunkov <asml.silence@gmail.com>]

Hi Anuj,

On 10/19/26 14:40, Anuj Gupta wrote:
> On Sun, Oct 18, 2026 at 11:06:16PM +0100, Pavel Begunkov wrote:
>> On 10/16/26 11:34, Anuj Gupta wrote:
>>> From: Anuj Gupta <anuj20.g@samsung.com>
>>> diff --git a/drivers/nvme/host/ioctl.c b/drivers/nvme/host/ioctl.c
>>> index 3aa5d2f2dfbb..6343da1f6c05 100644
>>> --- a/drivers/nvme/host/ioctl.c
>>> +++ b/drivers/nvme/host/ioctl.c
>>> @@ -458,6 +458,7 @@ static enum rq_end_io_ret nvme_uring_cmd_end_io(struct request *req,
>>>    			status = blk_status_to_errno(err);
>>>    	}
>>>    	io_uring_cmd_set_res32(ioucmd, status, result);
>>> +	io_uring_cmd_detach_dmabuf(ioucmd);
>>
>> It's not great spilling the responsibility for [de,a]ttaching
>> between nvme and uring_cmd code. Is there a way to stash it
>> all under io_uring?
> 
> The natural place would be __io_uring_cmd_done(), but that runs from
> task_work, while the ref has to be dropped at hardware completion, like
> io_complete_rw() does.

It may queue a task work but is called from whenever. It would work
if we drop there and in __io_uring_cmd_do_in_task(), but I agree
with you that it might be confusing to the user.

> Hooking io_uring_cmd_do_in_task_lazy() would avoid changing the NVMe
> call site, but would add a non-obvious side effect to a generic
> task_work helper. How about a separate helper that drivers call from
> end_io instead? This keeps the dma-buf handling in io_uring while NVMe
> only reports that it has finished accessing the data.

Sounds the same, but I don't have a better answer, so either is
fine with me. At least with your versions we can add a warning
for misbehaving users.

-- 
Pavel Begunkov