All of 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: 27+ 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-12 13:08   ` Matthew Brost
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-12 20:21     ` Jens Axboe
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]
2026-10-12 20:16 ` [PATCH v9 00/13] Add dmabuf read/write via io_uring Jens Axboe
2026-10-12 20:21 ` Jens Axboe
2026-10-13 14:10   ` Christoph Hellwig

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.