From: Caleb Sander Mateos <csander@purestorage.com>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: miklos@szeredi.hu, axboe@kernel.dk, bschubert@ddn.com,
asml.silence@gmail.com, io-uring@vger.kernel.org,
xiaobing.li@samsung.com, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v3 08/25] io_uring: add io_uring_cmd_fixed_index_get() and io_uring_cmd_fixed_index_put()
Date: Thu, 8 Jan 2026 17:08:47 -0800 [thread overview]
Message-ID: <CADUfDZqm_nwWG=oSfL69hioag+KF0t3nUKTQFRfXMHgmHtQRjg@mail.gmail.com> (raw)
In-Reply-To: <CAJnrk1aC6x=NppNZX+3iit5weO-oPULfFEq2D=9vDAA-TBuFtw@mail.gmail.com>
On Thu, Jan 8, 2026 at 4:55 PM Joanne Koong <joannelkoong@gmail.com> wrote:
>
> On Thu, Jan 8, 2026 at 12:44 PM Caleb Sander Mateos
> <csander@purestorage.com> wrote:
> >
> > On Thu, Jan 8, 2026 at 11:02 AM Caleb Sander Mateos
> > <csander@purestorage.com> wrote:
> > >
> > > On Mon, Dec 22, 2025 at 4:36 PM Joanne Koong <joannelkoong@gmail.com> wrote:
> > > >
> > > > Add two new helpers, io_uring_cmd_fixed_index_get() and
> > > > io_uring_cmd_fixed_index_put(). io_uring_cmd_fixed_index_get()
> > > > constructs an iter for a fixed buffer at a given index and acquires a
> > > > refcount on the underlying node. io_uring_cmd_fixed_index_put()
> > > > decrements this refcount. The caller is responsible for ensuring
> > > > io_uring_cmd_fixed_index_put() is properly called for releasing the
> > > > refcount after it is done using the iter it obtained through
> > > > io_uring_cmd_fixed_index_get().
> > > >
> > > > This is a preparatory patch needed for fuse-over-io-uring support, as
> > > > the metadata for fuse requests will be stored at the last index, which
> > > > will be different from the buf index set on the sqe.
> > > >
> > > > Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> > > > ---
> > > > include/linux/io_uring/cmd.h | 20 +++++++++++
> > > > io_uring/rsrc.c | 65 ++++++++++++++++++++++++++++++++++++
> > > > io_uring/rsrc.h | 5 +++
> > > > io_uring/uring_cmd.c | 21 ++++++++++++
> > > > 4 files changed, 111 insertions(+)
> > > >
> > > > diff --git a/io_uring/rsrc.c b/io_uring/rsrc.c
> > > > index a63474b331bf..a141aaeb099d 100644
> > > > --- a/io_uring/rsrc.c
> > > > +++ b/io_uring/rsrc.c
> > > > @@ -1151,6 +1151,71 @@ int io_import_reg_buf(struct io_kiocb *req, struct iov_iter *iter,
> > > > return io_import_fixed(ddir, iter, node->buf, buf_addr, len);
> > > > }
> > > >
> > > > +int io_reg_buf_index_get(struct io_kiocb *req, struct iov_iter *iter,
> > > > + u16 buf_index, unsigned int off, size_t len,
> > > > + int ddir, unsigned issue_flags)
> > > > +{
> > > > + struct io_ring_ctx *ctx = req->ctx;
> > > > + struct io_rsrc_node *node;
> > > > + struct io_mapped_ubuf *imu;
> > > > + u64 addr;
> > > > + int err;
> > > > +
> > > > + io_ring_submit_lock(ctx, issue_flags);
> > > > +
> > > > + node = io_rsrc_node_lookup(&ctx->buf_table, buf_index);
> > > > + if (!node) {
> > > > + io_ring_submit_unlock(ctx, issue_flags);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + node->refs++;
> > > > +
> > > > + io_ring_submit_unlock(ctx, issue_flags);
> > > > +
> > > > + imu = node->buf;
> > > > + if (!imu) {
> > > > + err = -EFAULT;
> > > > + goto error;
> > > > + }
> > > > +
> > > > + if (check_add_overflow(imu->ubuf, off, &addr)) {
> > > > + err = -EINVAL;
> > > > + goto error;
> > > > + }
> > > > +
> > > > + err = io_import_fixed(ddir, iter, imu, addr, len);
> > > > + if (err)
> > > > + goto error;
> > > > +
> > > > + return 0;
> > > > +
> > > > +error:
> > > > + io_reg_buf_index_put(req, buf_index, issue_flags);
> > > > + return err;
> > > > +}
> > > > +
> > > > +int io_reg_buf_index_put(struct io_kiocb *req, u16 buf_index,
> > > > + unsigned issue_flags)
> > > > +{
> > > > + struct io_ring_ctx *ctx = req->ctx;
> > > > + struct io_rsrc_node *node;
> > > > +
> > > > + io_ring_submit_lock(ctx, issue_flags);
> > > > +
> > > > + node = io_rsrc_node_lookup(&ctx->buf_table, buf_index);
> > >
> > > Hmm, I don't think it's safe to assume this node looked up by
> > > buf_index matches the one obtained in io_reg_buf_index_get(). Since
> > > the uring_lock is released between io_reg_buf_index_get() and
> > > io_reg_buf_index_put(), an intervening IORING_REGISTER_BUFFERS_UPDATE
> > > operation may modify the node at buf_index in the buf_table. That
> > > could result in a reference decrement on the wrong node, resulting in
> > > the new node being freed while still in use.
> > > Can we return the struct io_rsrc_node * from io_reg_buf_index_get()
> > > and pass it to io_reg_buf_index_put() in place of buf_index?
> >
> > Alternatively, store the struct io_rsrc_node * in the struct io_kiocb,
> > as io_find_buf_node() does? Then you wouldn't even need to call
> > io_reg_buf_index_put(); io_uring would automatically release the
> > buffer node reference upon completion of the request. The only reason
> > I can see why that wouldn't work is if a single fuse io_uring_cmd
> > needs to import multiple registered buffers. But it doesn't look like
> > that's the case from my quick skim of the fuse code.
>
> Good catch, I think I'll need to store that rsrc node pointer inside
> the fuse code then. I think we could store it inside the struct
> io_kiocb for the fuse use case but I think at an api level that ends
> up getting ugly with introducing unobvious relationships between
> io_uring_cmd_fixed_index_get() and io_uring_cmd_import_fixed().
Perhaps renaming it to something more similar
("io_uring_cmd_import_fixed_index()" or something) would help hint
that these 2 functions are related? But I'm fine with storing the
struct io_rsrc_node * externally if you'd prefer that.
Best,
Caleb
next prev parent reply other threads:[~2026-01-09 1:08 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-23 0:34 [PATCH v3 00/25] fuse/io-uring: add kernel-managed buffer rings and zero-copy Joanne Koong
2025-12-23 0:34 ` [PATCH v3 01/25] io_uring/kbuf: refactor io_buf_pbuf_register() logic into generic helpers Joanne Koong
2025-12-23 0:34 ` [PATCH v3 02/25] io_uring/kbuf: rename io_unregister_pbuf_ring() to io_unregister_buf_ring() Joanne Koong
2025-12-23 0:35 ` [PATCH v3 03/25] io_uring/kbuf: add support for kernel-managed buffer rings Joanne Koong
2025-12-23 0:35 ` [PATCH v3 04/25] io_uring/kbuf: add mmap " Joanne Koong
2025-12-23 0:35 ` [PATCH v3 05/25] io_uring/kbuf: support kernel-managed buffer rings in buffer selection Joanne Koong
2026-01-03 22:45 ` Caleb Sander Mateos
2026-01-09 0:56 ` Joanne Koong
2025-12-23 0:35 ` [PATCH v3 06/25] io_uring/kbuf: add buffer ring pinning/unpinning Joanne Koong
2025-12-29 21:07 ` Gabriel Krisman Bertazi
2025-12-30 1:27 ` Joanne Koong
2025-12-30 17:54 ` Gabriel Krisman Bertazi
2026-01-02 17:57 ` Joanne Koong
2026-01-08 18:40 ` Caleb Sander Mateos
2026-01-08 19:18 ` Caleb Sander Mateos
2026-01-09 1:04 ` Joanne Koong
2025-12-23 0:35 ` [PATCH v3 07/25] io_uring/kbuf: add recycling for kernel managed buffer rings Joanne Koong
2025-12-29 22:00 ` Gabriel Krisman Bertazi
2025-12-29 22:20 ` Gabriel Krisman Bertazi
2025-12-30 1:15 ` Joanne Koong
2026-01-05 18:49 ` Gabriel Krisman Bertazi
2026-01-08 20:37 ` Caleb Sander Mateos
2026-01-09 1:07 ` Joanne Koong
2025-12-23 0:35 ` [PATCH v3 08/25] io_uring: add io_uring_cmd_fixed_index_get() and io_uring_cmd_fixed_index_put() Joanne Koong
2026-01-08 19:02 ` Caleb Sander Mateos
2026-01-08 20:44 ` Caleb Sander Mateos
2026-01-09 0:55 ` Joanne Koong
2026-01-09 1:08 ` Caleb Sander Mateos [this message]
2025-12-23 0:35 ` [PATCH v3 09/25] io_uring/kbuf: add io_uring_cmd_is_kmbuf_ring() Joanne Koong
2025-12-23 0:35 ` [PATCH v3 10/25] io_uring/kbuf: export io_ring_buffer_select() Joanne Koong
2026-01-08 20:34 ` Caleb Sander Mateos
2026-01-09 0:38 ` Joanne Koong
2026-01-09 2:43 ` Caleb Sander Mateos
2025-12-23 0:35 ` [PATCH v3 11/25] io_uring/kbuf: return buffer id in buffer selection Joanne Koong
2025-12-23 0:35 ` [PATCH v3 12/25] io_uring/cmd: set selected buffer index in __io_uring_cmd_done() Joanne Koong
2025-12-23 0:35 ` [PATCH v3 13/25] fuse: refactor io-uring logic for getting next fuse request Joanne Koong
2025-12-23 0:35 ` [PATCH v3 14/25] fuse: refactor io-uring header copying to ring Joanne Koong
2026-01-11 16:03 ` Bernd Schubert
2026-01-16 22:33 ` Joanne Koong
2026-01-27 23:06 ` Bernd Schubert
2025-12-23 0:35 ` [PATCH v3 15/25] fuse: refactor io-uring header copying from ring Joanne Koong
2025-12-23 0:35 ` [PATCH v3 16/25] fuse: use enum types for header copying Joanne Koong
2025-12-23 0:35 ` [PATCH v3 17/25] fuse: refactor setting up copy state for payload copying Joanne Koong
2025-12-23 0:35 ` [PATCH v3 18/25] fuse: support buffer copying for kernel addresses Joanne Koong
2025-12-23 0:35 ` [PATCH v3 19/25] fuse: add io-uring kernel-managed buffer ring Joanne Koong
2026-02-03 23:58 ` Bernd Schubert
2026-02-05 20:24 ` Joanne Koong
2026-02-05 20:49 ` Bernd Schubert
2026-02-05 21:29 ` Joanne Koong
2026-02-05 21:48 ` Bernd Schubert
2026-02-05 22:19 ` Joanne Koong
2025-12-23 0:35 ` [PATCH v3 20/25] io_uring/rsrc: rename io_buffer_register_bvec()/io_buffer_unregister_bvec() Joanne Koong
2026-01-08 20:52 ` Caleb Sander Mateos
2025-12-23 0:35 ` [PATCH v3 21/25] io_uring/rsrc: split io_buffer_register_request() logic Joanne Koong
2026-01-08 21:04 ` Caleb Sander Mateos
2026-01-09 0:18 ` Joanne Koong
2025-12-23 0:35 ` [PATCH v3 22/25] io_uring/rsrc: Allow buffer release callback to be optional Joanne Koong
2025-12-23 0:35 ` [PATCH v3 23/25] io_uring/rsrc: add io_buffer_register_bvec() Joanne Koong
2026-01-08 21:09 ` Caleb Sander Mateos
2026-01-09 0:10 ` Joanne Koong
2025-12-23 0:35 ` [PATCH v3 24/25] fuse: add zero-copy over io-uring Joanne Koong
2026-01-08 21:15 ` Caleb Sander Mateos
2026-01-09 0:07 ` Joanne Koong
2025-12-23 0:35 ` [PATCH v3 25/25] docs: fuse: add io-uring bufring and zero-copy documentation Joanne Koong
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='CADUfDZqm_nwWG=oSfL69hioag+KF0t3nUKTQFRfXMHgmHtQRjg@mail.gmail.com' \
--to=csander@purestorage.com \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=bschubert@ddn.com \
--cc=io-uring@vger.kernel.org \
--cc=joannelkoong@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=xiaobing.li@samsung.com \
/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