All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Caleb Sander Mateos <csander@purestorage.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org,
	Uday Shankar <ushankar@purestorage.com>
Subject: Re: [PATCH 2/4] ublk: enhance check for register/unregister io buffer command
Date: Sun, 27 Apr 2025 09:37:02 +0800	[thread overview]
Message-ID: <aA2KPuQl1_hTlplG@fedora> (raw)
In-Reply-To: <CADUfDZrF71gPfCghE+wNyLXTmtAUprMfpo1XtP1C7kxx-=eP+w@mail.gmail.com>

On Sat, Apr 26, 2025 at 01:38:14PM -0700, Caleb Sander Mateos wrote:
> On Sat, Apr 26, 2025 at 2:41 AM Ming Lei <ming.lei@redhat.com> wrote:
> >
> > The simple check of UBLK_IO_FLAG_OWNED_BY_SRV can avoid incorrect
> > register/unregister io buffer easily, so check it before calling
> > starting to register/un-register io buffer.
> >
> > Also only allow io buffer register/unregister uring_cmd in case of
> > UBLK_F_SUPPORT_ZERO_COPY.
> 
> Indeed, both these checks make sense. (Hopefully there aren't any
> applications depending on the ability to use ublk zero-copy without
> setting the flag.) I too was thinking of adding the
> UBLK_IO_FLAG_OWNED_BY_SRV check because it could allow the
> kref_get_unless_zero() to be replaced with the cheaper kref_get(). I
> think the checks could be split into 2 separate commits, but up to
> you.

Let's do it in single patch for making everyone easier.

> 
> >
> > Fixes: 1f6540e2aabb ("ublk: zc register/unregister bvec")
> > Signed-off-by: Ming Lei <ming.lei@redhat.com>
> > ---
> >  drivers/block/ublk_drv.c | 23 ++++++++++++++++++++++-
> >  1 file changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> > index 40f971a66d3e..347790b3a633 100644
> > --- a/drivers/block/ublk_drv.c
> > +++ b/drivers/block/ublk_drv.c
> > @@ -609,6 +609,11 @@ static void ublk_apply_params(struct ublk_device *ub)
> >                 ublk_dev_param_zoned_apply(ub);
> >  }
> >
> > +static inline bool ublk_support_zero_copy(const struct ublk_queue *ubq)
> > +{
> > +       return ubq->flags & UBLK_F_SUPPORT_ZERO_COPY;
> > +}
> > +
> >  static inline bool ublk_support_user_copy(const struct ublk_queue *ubq)
> >  {
> >         return ubq->flags & (UBLK_F_USER_COPY | UBLK_F_SUPPORT_ZERO_COPY);
> > @@ -1950,9 +1955,16 @@ static int ublk_register_io_buf(struct io_uring_cmd *cmd,
> >                                 unsigned int index, unsigned int issue_flags)
> >  {
> >         struct ublk_device *ub = cmd->file->private_data;
> > +       struct ublk_io *io = &ubq->ios[tag];
> 
> I thought you had mentioned in
> https://lore.kernel.org/linux-block/aAmYJxaV1-yWEMRo@fedora/ wanting
> to the ability to offload the ublk zero-copy buffer registration to a
> thread other than ubq_daemon. Are you still planning to do that, or
> does the "auto-register" feature supplant the need for that?

The auto-register idea is actually thought of when I was working on ublk
selftest offload function.

If this auto-register feature is supported, it becomes less important to
relax the ubq_daemon limit for register_io_buffer command, then I jump
on this feature & post put the patch.

But I will continue to work on the offload test code and finally relax
the limit for register/unregister io buffer command, hope it can be
done in next week.

> Accessing
> the ublk_io here only seems safe when on the ubq_daemon thread.

Both ublk_register_io_buf()/ublk_unregister_io_buf() just reads ublk_io or
the request buffer only, so it is just fine for the two to run from other
contexts.

> 
> >         struct request *req;
> >         int ret;
> >
> > +       if (!ublk_support_zero_copy(ubq))
> > +               return -EINVAL;
> > +
> > +       if (!(io->flags & UBLK_IO_FLAG_OWNED_BY_SRV))
> > +               return -EINVAL;
> 
> Every opcode except UBLK_IO_FETCH_REQ now checks io->flags &
> UBLK_IO_FLAG_OWNED_BY_SRV. Maybe it would make sense to lift the check
> up to __ublk_ch_uring_cmd() to avoid duplicating it?

Good point.


Thanks, 
Ming


  reply	other threads:[~2025-04-27  1:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-26  9:41 [PATCH 0/4] ublk: two fixes and support UBLK_F_AUTO_ZERO_COPY Ming Lei
2025-04-26  9:41 ` [PATCH 1/4] selftests: ublk: fix UBLK_F_NEED_GET_DATA Ming Lei
2025-04-26 20:15   ` Caleb Sander Mateos
2025-04-27  1:26     ` Ming Lei
2025-04-26  9:41 ` [PATCH 2/4] ublk: enhance check for register/unregister io buffer command Ming Lei
2025-04-26 20:38   ` Caleb Sander Mateos
2025-04-27  1:37     ` Ming Lei [this message]
2025-04-27  3:14       ` Caleb Sander Mateos
2025-04-27  3:49         ` Ming Lei
2025-04-26  9:41 ` [PATCH 3/4] ublk: add feature UBLK_F_AUTO_ZERO_COPY Ming Lei
2025-04-26 22:42   ` Caleb Sander Mateos
2025-04-27  2:06     ` Ming Lei
2025-04-27  3:09       ` Caleb Sander Mateos
2025-04-27  3:15         ` Ming Lei
2025-04-27  2:34     ` Keith Busch
2025-04-27  3:10       ` Ming Lei
2025-04-27  4:04         ` Keith Busch
2025-04-27  7:32           ` Ming Lei
2025-04-26  9:41 ` [PATCH 4/4] selftests: ublk: support UBLK_F_AUTO_ZERO_COPY 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=aA2KPuQl1_hTlplG@fedora \
    --to=ming.lei@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=csander@purestorage.com \
    --cc=linux-block@vger.kernel.org \
    --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 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.