From: Clay Mayers <[email protected]>
To: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: RE: [RFC 02/13] nvme: wire-up support for async-passthru on
Date: Tue, 21 Dec 2021 21:16:27 +0000 [thread overview]
Message-ID: <[email protected]> (raw)
Message-ID: <[email protected]>
On 12/20/21 19:47:23 +0530, Kanchan Joshi wrote:
> Introduce handlers for fops->async_cmd(), implementing async passthru on
> char device (including the multipath one).
> The handlers supports NVME_IOCTL_IO64_CMD.
>
I commented on these two issues below in more detail at
https://github.com/joshkan/nvme-uring-pt/issues
> +static void nvme_setup_uring_cmd_data(struct request *rq,
> + struct io_uring_cmd *ioucmd, void *meta,
> + void __user *meta_buffer, u32 meta_len, bool write) {
> + struct nvme_uring_cmd *cmd = nvme_uring_cmd(ioucmd);
> +
> + /* to free bio on completion, as req->bio will be null at that time */
> + cmd->bio = rq->bio;
> + /* meta update is required only for read requests */
> + if (meta && !write) {
> + cmd->meta = meta;
> + cmd->meta_buffer = meta_buffer;
> + cmd->meta_len = meta_len;
> + } else {
> + cmd->meta = NULL;
I believe that not saving meta in cmd->meta will leak it when it's a write.
But nvme_pt_task_cb also needs to change to copy to user when
cmd->meta_buffer is set instead of cmd->meta.
> +
> +int nvme_ns_chr_async_cmd(struct io_uring_cmd *ioucmd,
> + enum io_uring_cmd_flags flags)
> +{
> + struct nvme_ns *ns = container_of(file_inode(ioucmd->file)->i_cdev,
> + struct nvme_ns, cdev);
> +
> + return nvme_ns_async_ioctl(ns, ioucmd); }
> +
The uring cmd flags are not being passed to nvme_ns_async_ioctl - what if
IO_URING_F_NONBLOCK Is set? When it is, I think the nvme_alloc_request()
call in nvme_submit_user_cmd() needs to pass in BLK_MQ_REQ_NOWAIT as
the flags parameter or move to another thread. Our proto-type does the former
requiring user mode to retry on -EWOULDBLOCK and -EBUSY.
--
Clay Mayers
next reply other threads:[~2021-12-21 21:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-21 21:16 Clay Mayers [this message]
2021-12-22 8:02 ` [RFC 02/13] nvme: wire-up support for async-passthru on hch
2021-12-22 15:11 ` Clay Mayers
2021-12-22 13:46 ` Kanchan Joshi
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 \
[email protected] \
[email protected] \
[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