dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Pavel Begunkov" <asml.silence@gmail.com>
Cc: media-ci@linuxtv.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v9 13/13] io_uring/rsrc: add dmabuf backed registered buffers
Date: Wed, 07 Oct 2026 01:55:48 +0000	[thread overview]
Message-ID: <sashiko-outbox-162573@kernel.org> (raw)
In-Reply-To: <a71d400980af9de2724bcc5d201040a930eecaf4.1791336930.git.asml.silence@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] io_uring/rw: dmabuf_map memory leak upon request reissue overwriting req->dmabuf_map
- [High] io_uring/rsrc: dmabuf_map leak via cloning dmabuf to IOPOLL ring bypassing restrictions
--

commit 6cf565430e55d29c9af3badb73c4c8775d233005
Author: Pavel Begunkov <asml.silence@gmail.com>

    io_uring/rsrc: add dmabuf backed registered buffers
    
    Implement dmabuf backed registered buffers. To register them, the user
    should specify IO_REGBUF_TYPE_DMABUF for the regitration and pass the
    desired dmabuf fd and a file for which it should be registered.

> diff --git a/io_uring/dma-buf.c b/io_uring/dma-buf.c
> index 0000000000000..f40c9d87ed8aa
> --- /dev/null
> +++ b/io_uring/dma-buf.c
[ ... ]
> +int io_register_dmabuf(struct io_ring_ctx *ctx,
> +			struct io_uring_regbuf_desc *desc,
> +			struct io_mapped_ubuf *imu)
> +{
[ ... ]
> +	if (ctx->flags & IORING_SETUP_IOPOLL)
> +		return -EOPNOTSUPP;
[ ... ]
> +	bd->target_file = target_file;
> +	imu->len = dmabuf->size;
> +	imu->release = io_release_dmabuf;
> +	imu->priv = bd;
> +	imu->flags = IO_REGBUF_F_DMABUF;
> +	imu->dir = IO_BUF_DEST | IO_BUF_SOURCE;
> +	dma_buf_put(dmabuf);
> +	return 0;

[Severity: High]
Should IO_REGBUF_F_UNCLONEABLE be included in imu->flags here to prevent 
IOPOLL rings from cloning this buffer?

While io_register_dmabuf() explicitly rejects rings with IORING_SETUP_IOPOLL 
set during initial registration, omitting the uncloneable flag allows an 
IOPOLL ring to bypass this restriction by cloning the dmabuf via 
io_clone_buffers().

If the buffer is cloned to an IOPOLL ring, polled I/O requests will finish 
via io_complete_rw_iopoll(), which does not call io_detach_dmabuf_map(req) 
(unlike io_complete_rw). Does this result in a permanent leak of the 
dma_buf_io_map reference for any async polled request?

> diff --git a/io_uring/dma-buf.h b/io_uring/dma-buf.h
> index 0000000000000..10d2efdd8c9f1
> --- /dev/null
> +++ b/io_uring/dma-buf.h
[ ... ]
> +static inline int io_attach_dmabuf_map(struct io_kiocb *req,
> +					struct iov_iter *iter,
> +					unsigned issue_flags)
> +{
[ ... ]
> +	bd = req->buf_node->buf->priv;
> +	map = dma_buf_io_get_map(bd->ctx, nowait);
> +	if (unlikely(IS_ERR(map)))
> +		return PTR_ERR(map);
> +	req->dmabuf_map = map;
> +	iter->dmabuf_map = map;
> +	return 0;
> +}

[Severity: High]
Could this overwrite and leak the previous req->dmabuf_map if the request 
is reissued?

When a read or write request encounters a reissue condition, it returns 
-EIOCBQUEUED. In io_read_fixed() and io_write_fixed(), this causes it to 
skip calling io_detach_dmabuf_map().

When the request is subsequently reissued, it executes io_init_rw_fixed() 
again, which unconditionally calls io_attach_dmabuf_map(). This fetches a 
new map and overwrites req->dmabuf_map without dropping the previous 
reference.

Would it make sense to check if req->dmabuf_map is already populated before 
requesting and assigning a new map, or to ensure it is detached before 
reassignment?

> diff --git a/io_uring/rw.c b/io_uring/rw.c
> index 432820f862514..ba0e3e7de557d 100644
> --- a/io_uring/rw.c
> +++ b/io_uring/rw.c
[ ... ]
> @@ -363,13 +364,18 @@ static int io_init_rw_fixed(struct io_kiocb *req, unsigned int issue_flags,
>  	struct io_async_rw *io = req->async_data;
>  	int ret;
>  
> -	if (io->bytes_done)
> -		return 0;
> +	if (!io->bytes_done) {
> +		ret = __io_import_reg_buf(req, &io->iter, rw->addr, rw->len, ddir,
> +					  issue_flags, IO_REGBUF_IMPORT_ALLOW_DMABUF);
> +		if (ret)
> +			return ret;
> +		iov_iter_save_state(&io->iter, &io->iter_state);
> +	}
>  
> -	ret = io_import_reg_buf(req, &io->iter, rw->addr, rw->len, ddir,
> -				issue_flags);
> -	iov_iter_save_state(&io->iter, &io->iter_state);
> -	return ret;
> +	ret = io_attach_dmabuf_map(req, &io->iter, issue_flags);
> +	if (ret)
> +		return ret;
> +	return 0;
>  }
[ ... ]
> @@ -1231,7 +1239,10 @@ int io_read_fixed(struct io_kiocb *req, unsigned int issue_flags)
>  	if (unlikely(ret))
>  		return ret;
>  
> -	return io_read(req, issue_flags);
> +	ret = io_read(req, issue_flags);
> +	if (ret != -EIOCBQUEUED)
> +		io_detach_dmabuf_map(req);
> +	return ret;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1791336930.git.asml.silence@gmail.com?part=13

      reply	other threads:[~2026-10-07  1:55 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07  1:42 [PATCH v9 00/13] Add dmabuf read/write via io_uring Pavel Begunkov
2026-10-07  1:42 ` [PATCH v9 01/13] dma-buf: introduce initial file I/O infrastructure Pavel Begunkov
2026-10-07  1:52   ` sashiko-bot
2026-10-07  1:42 ` [PATCH v9 02/13] iov_iter: add iterator type for dmabuf maps Pavel Begunkov
2026-10-07  1:57   ` sashiko-bot
2026-10-07  1:42 ` [PATCH v9 03/13] block: always adjust bi_offset on bio_advance_iter Pavel Begunkov
2026-10-07  1:42 ` [PATCH v9 04/13] block: introduce dma map backed bio type Pavel Begunkov
2026-10-07  1:59   ` sashiko-bot
2026-10-07  1:42 ` [PATCH v9 05/13] block: add dma-buf support for raw bdev Pavel Begunkov
2026-10-08 12:27   ` Anuj Gupta/Anuj Gupta
2026-10-07  1:42 ` [PATCH v9 06/13] nvme-pci: rename nvme_pci_sgl_set_data to nvme_pci_dma_iter_set_sgl Pavel Begunkov
2026-10-07  1:42 ` [PATCH v9 07/13] nvme-pci: implement dma-buf backed requests Pavel Begunkov
2026-10-07  2:01   ` sashiko-bot
2026-10-07  1:42 ` [PATCH v9 08/13] nvme-pci: add SGL support for the dmabuf path Pavel Begunkov
2026-10-07  2:00   ` sashiko-bot
2026-10-07  1:42 ` [PATCH v9 09/13] io_uring/rsrc: introduce buf registration structure Pavel Begunkov
2026-10-07  1:42 ` [PATCH v9 10/13] io_uring/rsrc: extend buffer update Pavel Begunkov
2026-10-07  1:51   ` sashiko-bot
2026-10-07  1:42 ` [PATCH v9 11/13] io_uring/rsrc: add uncloneable regbuf flag Pavel Begunkov
2026-10-07  1:42 ` [PATCH v9 12/13] io_uring/rsrc: add regbuf import flags Pavel Begunkov
2026-10-07  1:42 ` [PATCH v9 13/13] io_uring/rsrc: add dmabuf backed registered buffers Pavel Begunkov
2026-10-07  1:55   ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-162573@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=asml.silence@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=media-ci@linuxtv.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox