public inbox for io-uring@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Begunkov <asml.silence@gmail.com>
To: Ming Lei <ming.lei@redhat.com>, Jens Axboe <axboe@kernel.dk>,
	io-uring@vger.kernel.org, linux-block@vger.kernel.org
Cc: Uday Shankar <ushankar@purestorage.com>,
	Caleb Sander Mateos <csander@purestorage.com>,
	Keith Busch <kbusch@kernel.org>
Subject: Re: [RFC PATCH 3/7] io_uring: support to register bvec buffer to specified io_uring
Date: Mon, 28 Apr 2025 11:28:30 +0100	[thread overview]
Message-ID: <0c542e65-d203-4a3e-b9fd-aa090c144afd@gmail.com> (raw)
In-Reply-To: <20250428094420.1584420-4-ming.lei@redhat.com>

On 4/28/25 10:44, Ming Lei wrote:
> Extend io_buffer_register_bvec() and io_buffer_unregister_bvec() for
> supporting to register/unregister bvec buffer to specified io_uring,
> which FD is usually passed from userspace.
> 
> Signed-off-by: Ming Lei <ming.lei@redhat.com>
> ---
>   include/linux/io_uring/cmd.h |  4 ++
>   io_uring/rsrc.c              | 83 +++++++++++++++++++++++++++---------
>   2 files changed, 67 insertions(+), 20 deletions(-)
> 
> diff --git a/include/linux/io_uring/cmd.h b/include/linux/io_uring/cmd.h
> index 78fa336a284b..7516fe5cd606 100644
> --- a/include/linux/io_uring/cmd.h
> +++ b/include/linux/io_uring/cmd.h
> @@ -25,6 +25,10 @@ struct io_uring_cmd_data {
...
>   	io_ring_submit_lock(ctx, issue_flags);
> -	ret = __io_buffer_unregister_bvec(ctx, buf);
> +	if (reg)
> +		ret = __io_buffer_register_bvec(ctx, buf);
> +	else
> +		ret = __io_buffer_unregister_bvec(ctx, buf);
>   	io_ring_submit_unlock(ctx, issue_flags);
>   
>   	return ret;
>   }
> +
> +static int io_buffer_reg_unreg_bvec(struct io_ring_ctx *ctx,
> +				    struct io_buf_data *buf,
> +				    unsigned int issue_flags,
> +				    bool reg)
> +{
> +	struct io_ring_ctx *remote_ctx = ctx;
> +	struct file *file = NULL;
> +	int ret;
> +
> +	if (buf->has_fd) {
> +		file = io_uring_register_get_file(buf->ring_fd, buf->registered_fd);

io_uring_register_get_file() accesses task private data and the request
doesn't control from which task it's executed. IOW, you can't use the
helper here. It can be iowq or sqpoll, but either way nothing is
promised.

> +		if (IS_ERR(file))
> +			return PTR_ERR(file);
> +		remote_ctx = file->private_data;
> +		if (!remote_ctx)
> +			return -EINVAL;

nit: this check is not needed.

> +	}
> +
> +	if (remote_ctx == ctx) {
> +		do_reg_unreg_bvec(ctx, buf, issue_flags, reg);
> +	} else {
> +		if (!(issue_flags & IO_URING_F_UNLOCKED))
> +			mutex_unlock(&ctx->uring_lock);

We shouldn't be dropping the lock in random helpers, for example
it'd be pretty nasty suspending a submission loop with a submission
from another task.

You can try lock first, if fails it'll need a fresh context via
iowq to be task-work'ed into the ring. see msg_ring.c for how
it's done for files.

> +
> +		do_reg_unreg_bvec(remote_ctx, buf, IO_URING_F_UNLOCKED, reg);
> +
> +		if (!(issue_flags & IO_URING_F_UNLOCKED))
> +			mutex_lock(&ctx->uring_lock);
> +	}
> +
> +	if (file)
> +		fput(file);
> +
> +	return ret;
> +}
-- 
Pavel Begunkov


  reply	other threads:[~2025-04-28 10:27 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-28  9:44 [RFC PATCH 0/7] ublk: support to register bvec buffer automatically Ming Lei
2025-04-28  9:44 ` [RFC PATCH 1/7] io_uring: add 'struct io_buf_data' for register/unregister bvec buffer Ming Lei
2025-04-29  0:35   ` Caleb Sander Mateos
2025-04-28  9:44 ` [RFC PATCH 2/7] io_uring: add helper __io_buffer_[un]register_bvec Ming Lei
2025-04-29  0:36   ` Caleb Sander Mateos
2025-04-28  9:44 ` [RFC PATCH 3/7] io_uring: support to register bvec buffer to specified io_uring Ming Lei
2025-04-28 10:28   ` Pavel Begunkov [this message]
2025-04-29  0:46     ` Caleb Sander Mateos
2025-04-29  0:47     ` Ming Lei
2025-04-30  8:25       ` Pavel Begunkov
2025-04-30 14:44         ` Ming Lei
2025-04-29  0:43   ` Caleb Sander Mateos
2025-04-30 15:34     ` Ming Lei
2025-05-02  1:31       ` Caleb Sander Mateos
2025-05-02 15:59         ` Ming Lei
2025-05-02 21:21           ` Caleb Sander Mateos
2025-05-03  1:00             ` Ming Lei
2025-05-03 18:55               ` Caleb Sander Mateos
2025-05-06  2:45                 ` Ming Lei
2025-04-28  9:44 ` [RFC PATCH 4/7] ublk: convert to refcount_t Ming Lei
2025-04-28 17:13   ` Caleb Sander Mateos
2025-04-28  9:44 ` [RFC PATCH 5/7] ublk: prepare for supporting to register request buffer automatically Ming Lei
2025-04-29  0:50   ` Caleb Sander Mateos
2025-04-28  9:44 ` [RFC PATCH 6/7] ublk: register buffer to specified io_uring & buf index via UBLK_F_AUTO_BUF_REG Ming Lei
2025-04-29  0:52   ` Caleb Sander Mateos
2025-04-30 15:45     ` Ming Lei
2025-04-30 16:30       ` Caleb Sander Mateos
2025-05-02 14:09         ` Ming Lei
2025-04-28  9:44 ` [RFC PATCH 7/7] selftests: ublk: support UBLK_F_AUTO_BUF_REG Ming Lei

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=0c542e65-d203-4a3e-b9fd-aa090c144afd@gmail.com \
    --to=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=csander@purestorage.com \
    --cc=io-uring@vger.kernel.org \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=ushankar@purestorage.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