From: Keith Busch <[email protected]>
To: Pavel Begunkov <[email protected]>
Cc: Keith Busch <[email protected]>,
[email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected]
Subject: Re: [PATCHv7 2/6] io_uring: add support for kernel registered bvecs
Date: Thu, 27 Feb 2025 15:45:51 -0700 [thread overview]
Message-ID: <Z8DrH7sBSS752Z3o@kbusch-mbp> (raw)
In-Reply-To: <[email protected]>
On Thu, Feb 27, 2025 at 03:54:31PM +0000, Pavel Begunkov wrote:
> On 2/26/25 18:20, Keith Busch wrote:
> > From: Keith Busch <[email protected]>
> >
> > Provide an interface for the kernel to leverage the existing
> > pre-registered buffers that io_uring provides. User space can reference
> > these later to achieve zero-copy IO.
> >
> > User space must register an empty fixed buffer table with io_uring in
> > order for the kernel to make use of it.
>
> Can you also fail rw.c:loop_rw_iter()? Something like:
>
> loop_rw_iter() {
> if ((req->flags & REQ_F_BUF_NODE) &&
> req->buf_node->buf->release)
> return -EFAULT;
> }
For posterity: the suggestion is because this function uses the
file_operations' .read/.write callbacks, which expect __user pointers.
Playing devil's advocate here, I don't see how user space might know
ahead of time if the file they opened implements the supported _iter
versions. I think only esoteric and legacy interfaces still use it, so
maybe we don't care.
next prev parent reply other threads:[~2025-02-27 22:45 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-26 18:20 [PATCHv7 0/6] ublk zero copy support Keith Busch
2025-02-26 18:20 ` [PATCHv7 1/6] io_uring/rw: move fixed buffer import to issue path Keith Busch
2025-02-26 19:04 ` Jens Axboe
2025-02-26 20:20 ` Jens Axboe
2025-02-27 21:46 ` Keith Busch
2025-02-26 18:20 ` [PATCHv7 2/6] io_uring: add support for kernel registered bvecs Keith Busch
2025-02-26 20:36 ` Jens Axboe
2025-02-27 15:54 ` Pavel Begunkov
2025-02-27 16:04 ` Jens Axboe
2025-02-27 22:45 ` Keith Busch [this message]
2025-02-28 12:19 ` Pavel Begunkov
2025-02-26 18:20 ` [PATCHv7 3/6] nvme: map uring_cmd data even if address is 0 Keith Busch
2025-02-26 18:20 ` [PATCHv7 4/6] ublk: zc register/unregister bvec Keith Busch
2025-02-26 18:40 ` Jens Axboe
2025-02-26 18:21 ` [PATCHv7 5/6] io_uring: add abstraction for buf_table rsrc data Keith Busch
2025-02-26 18:21 ` [PATCHv7 6/6] io_uring: cache nodes and mapped buffers Keith Busch
2025-02-26 18:48 ` Jens Axboe
2025-02-26 19:36 ` Jens Axboe
2025-02-26 19:43 ` Jens Axboe
2025-02-26 19:58 ` Jens Axboe
2025-02-26 20:00 ` Keith Busch
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=Z8DrH7sBSS752Z3o@kbusch-mbp \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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