From: Christoph Hellwig <hch@lst.de>
To: Kanchan Joshi <joshi.k@samsung.com>
Cc: axboe@kernel.dk, hch@lst.de, kbusch@kernel.org,
chaitanya.kulkarni@wdc.com, io-uring@vger.kernel.org,
linux-nvme@lists.infradead.org, anuj20.g@samsung.com,
javier.gonz@samsung.com, nj.shetty@samsung.com,
selvakuma.s1@samsung.com
Subject: Re: [RFC PATCH v3 3/3] nvme: wire up support for async passthrough
Date: Wed, 17 Mar 2021 09:52:58 +0100 [thread overview]
Message-ID: <20210317085258.GA19580@lst.de> (raw)
In-Reply-To: <20210316140126.24900-4-joshi.k@samsung.com>
> +/*
> + * This is carved within the block_uring_cmd, to avoid dynamic allocation.
> + * Care should be taken not to grow this beyond what is available.
> + */
> +struct uring_cmd_data {
> + union {
> + struct bio *bio;
> + u64 result; /* nvme cmd result */
> + };
> + void *meta; /* kernel-resident buffer */
> + int status; /* nvme cmd status */
> +};
> +
> +inline u64 *ucmd_data_addr(struct io_uring_cmd *ioucmd)
> +{
> + return &(((struct block_uring_cmd *)&ioucmd->pdu)->unused[0]);
> +}
The whole typing is a mess, but this mostly goes back to the series
you're basing this on. Jens, can you send out the series so that
we can do a proper review?
IMHO struct io_uring_cmd needs to stay private in io-uring.c, and
the method needs to get the file and the untyped payload in form
of a void * separately. and block_uring_cmd should be private to
the example ioctl, not exposed to drivers implementing their own
schemes.
> +void ioucmd_task_cb(struct io_uring_cmd *ioucmd)
This should be mark static and have a much more descriptive name
including a nvme_ prefix.
> + /* handle meta update */
> + if (ucd->meta) {
> + void __user *umeta = nvme_to_user_ptr(ptcmd->metadata);
> +
> + if (!ucd->status)
> + if (copy_to_user(umeta, ucd->meta, ptcmd->metadata_len))
> + ucd->status = -EFAULT;
> + kfree(ucd->meta);
> + }
> + /* handle result update */
> + if (put_user(ucd->result, (u32 __user *)&ptcmd->result))
The comments aren't very useful, and the cast here is a warning sign.
Why do you need it?
> + ucd->status = -EFAULT;
> + io_uring_cmd_done(ioucmd, ucd->status);
Shouldn't the io-uring core take care of this io_uring_cmd_done
call?
> +void nvme_end_async_pt(struct request *req, blk_status_t err)
static?
> +{
> + struct io_uring_cmd *ioucmd;
> + struct uring_cmd_data *ucd;
> + struct bio *bio;
> + int ret;
> +
> + ioucmd = req->end_io_data;
> + ucd = (struct uring_cmd_data *) ucmd_data_addr(ioucmd);
> + /* extract bio before reusing the same field for status */
> + bio = ucd->bio;
> +
> + if (nvme_req(req)->flags & NVME_REQ_CANCELLED)
> + ucd->status = -EINTR;
> + else
> + ucd->status = nvme_req(req)->status;
> + ucd->result = le64_to_cpu(nvme_req(req)->result.u64);
> +
> + /* this takes care of setting up task-work */
> + ret = uring_cmd_complete_in_task(ioucmd, ioucmd_task_cb);
> + if (ret < 0)
> + kfree(ucd->meta);
> +
> + /* unmap pages, free bio, nvme command and request */
> + blk_rq_unmap_user(bio);
> + blk_mq_free_request(req);
How can we free the request here if the data is only copied out in
a task_work?
> static int nvme_submit_user_cmd(struct request_queue *q,
> struct nvme_command *cmd, void __user *ubuffer,
> unsigned bufflen, void __user *meta_buffer, unsigned meta_len,
> - u32 meta_seed, u64 *result, unsigned timeout)
> + u32 meta_seed, u64 *result, unsigned int timeout,
> + struct io_uring_cmd *ioucmd)
> {
> bool write = nvme_is_write(cmd);
> struct nvme_ns *ns = q->queuedata;
> @@ -1179,6 +1278,20 @@ static int nvme_submit_user_cmd(struct request_queue *q,
> req->cmd_flags |= REQ_INTEGRITY;
> }
> }
> + if (ioucmd) { /* async handling */
nvme_submit_user_cmd already is a mess. Please split this out into
a separate function. Maybe the logic to map the user buffers can be
split into a little shared helper.
> +int nvme_uring_cmd(struct request_queue *q, struct io_uring_cmd *ioucmd,
> + enum io_uring_cmd_flags flags)
Another comment on the original infrastructure: this really needs to
be a block_device_operations method taking a struct block_device instead
of being tied into blk-mq.
> +EXPORT_SYMBOL_GPL(nvme_uring_cmd);
I don't think this shoud be exported.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Kanchan Joshi <joshi.k@samsung.com>
Cc: axboe@kernel.dk, hch@lst.de, kbusch@kernel.org,
chaitanya.kulkarni@wdc.com, io-uring@vger.kernel.org,
linux-nvme@lists.infradead.org, anuj20.g@samsung.com,
javier.gonz@samsung.com, nj.shetty@samsung.com,
selvakuma.s1@samsung.com
Subject: Re: [RFC PATCH v3 3/3] nvme: wire up support for async passthrough
Date: Wed, 17 Mar 2021 09:52:58 +0100 [thread overview]
Message-ID: <20210317085258.GA19580@lst.de> (raw)
In-Reply-To: <20210316140126.24900-4-joshi.k@samsung.com>
> +/*
> + * This is carved within the block_uring_cmd, to avoid dynamic allocation.
> + * Care should be taken not to grow this beyond what is available.
> + */
> +struct uring_cmd_data {
> + union {
> + struct bio *bio;
> + u64 result; /* nvme cmd result */
> + };
> + void *meta; /* kernel-resident buffer */
> + int status; /* nvme cmd status */
> +};
> +
> +inline u64 *ucmd_data_addr(struct io_uring_cmd *ioucmd)
> +{
> + return &(((struct block_uring_cmd *)&ioucmd->pdu)->unused[0]);
> +}
The whole typing is a mess, but this mostly goes back to the series
you're basing this on. Jens, can you send out the series so that
we can do a proper review?
IMHO struct io_uring_cmd needs to stay private in io-uring.c, and
the method needs to get the file and the untyped payload in form
of a void * separately. and block_uring_cmd should be private to
the example ioctl, not exposed to drivers implementing their own
schemes.
> +void ioucmd_task_cb(struct io_uring_cmd *ioucmd)
This should be mark static and have a much more descriptive name
including a nvme_ prefix.
> + /* handle meta update */
> + if (ucd->meta) {
> + void __user *umeta = nvme_to_user_ptr(ptcmd->metadata);
> +
> + if (!ucd->status)
> + if (copy_to_user(umeta, ucd->meta, ptcmd->metadata_len))
> + ucd->status = -EFAULT;
> + kfree(ucd->meta);
> + }
> + /* handle result update */
> + if (put_user(ucd->result, (u32 __user *)&ptcmd->result))
The comments aren't very useful, and the cast here is a warning sign.
Why do you need it?
> + ucd->status = -EFAULT;
> + io_uring_cmd_done(ioucmd, ucd->status);
Shouldn't the io-uring core take care of this io_uring_cmd_done
call?
> +void nvme_end_async_pt(struct request *req, blk_status_t err)
static?
> +{
> + struct io_uring_cmd *ioucmd;
> + struct uring_cmd_data *ucd;
> + struct bio *bio;
> + int ret;
> +
> + ioucmd = req->end_io_data;
> + ucd = (struct uring_cmd_data *) ucmd_data_addr(ioucmd);
> + /* extract bio before reusing the same field for status */
> + bio = ucd->bio;
> +
> + if (nvme_req(req)->flags & NVME_REQ_CANCELLED)
> + ucd->status = -EINTR;
> + else
> + ucd->status = nvme_req(req)->status;
> + ucd->result = le64_to_cpu(nvme_req(req)->result.u64);
> +
> + /* this takes care of setting up task-work */
> + ret = uring_cmd_complete_in_task(ioucmd, ioucmd_task_cb);
> + if (ret < 0)
> + kfree(ucd->meta);
> +
> + /* unmap pages, free bio, nvme command and request */
> + blk_rq_unmap_user(bio);
> + blk_mq_free_request(req);
How can we free the request here if the data is only copied out in
a task_work?
> static int nvme_submit_user_cmd(struct request_queue *q,
> struct nvme_command *cmd, void __user *ubuffer,
> unsigned bufflen, void __user *meta_buffer, unsigned meta_len,
> - u32 meta_seed, u64 *result, unsigned timeout)
> + u32 meta_seed, u64 *result, unsigned int timeout,
> + struct io_uring_cmd *ioucmd)
> {
> bool write = nvme_is_write(cmd);
> struct nvme_ns *ns = q->queuedata;
> @@ -1179,6 +1278,20 @@ static int nvme_submit_user_cmd(struct request_queue *q,
> req->cmd_flags |= REQ_INTEGRITY;
> }
> }
> + if (ioucmd) { /* async handling */
nvme_submit_user_cmd already is a mess. Please split this out into
a separate function. Maybe the logic to map the user buffers can be
split into a little shared helper.
> +int nvme_uring_cmd(struct request_queue *q, struct io_uring_cmd *ioucmd,
> + enum io_uring_cmd_flags flags)
Another comment on the original infrastructure: this really needs to
be a block_device_operations method taking a struct block_device instead
of being tied into blk-mq.
> +EXPORT_SYMBOL_GPL(nvme_uring_cmd);
I don't think this shoud be exported.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2021-03-17 8:54 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20210316140229epcas5p23d68a4c9694bbf7759b5901115a4309b@epcas5p2.samsung.com>
2021-03-16 14:01 ` [RFC PATCH v3 0/3] Async nvme passthrough over io_uring Kanchan Joshi
2021-03-16 14:01 ` Kanchan Joshi
2021-03-16 14:01 ` [RFC PATCH v3 1/3] io_uring: add helper for uring_cmd completion in submitter-task Kanchan Joshi
2021-03-16 14:01 ` Kanchan Joshi
2021-03-16 15:43 ` Stefan Metzmacher
2021-03-16 15:43 ` Stefan Metzmacher
2021-03-18 1:57 ` Jens Axboe
2021-03-18 1:57 ` Jens Axboe
2021-03-18 5:25 ` Kanchan Joshi
2021-03-18 5:25 ` Kanchan Joshi
2021-03-18 5:48 ` Christoph Hellwig
2021-03-18 5:48 ` Christoph Hellwig
2021-03-18 6:14 ` Kanchan Joshi
2021-03-18 6:14 ` Kanchan Joshi
2021-03-16 14:01 ` [RFC PATCH v3 2/3] nvme: keep nvme_command instead of pointer to it Kanchan Joshi
2021-03-16 14:01 ` Kanchan Joshi
2021-03-16 17:16 ` Keith Busch
2021-03-16 17:16 ` Keith Busch
2021-03-17 9:38 ` Kanchan Joshi
2021-03-17 9:38 ` Kanchan Joshi
2021-03-17 14:17 ` Keith Busch
2021-03-17 14:17 ` Keith Busch
2021-03-16 14:01 ` [RFC PATCH v3 3/3] nvme: wire up support for async passthrough Kanchan Joshi
2021-03-16 14:01 ` Kanchan Joshi
2021-03-17 8:52 ` Christoph Hellwig [this message]
2021-03-17 8:52 ` Christoph Hellwig
2021-03-17 16:49 ` Jens Axboe
2021-03-17 16:49 ` Jens Axboe
2021-03-17 16:59 ` Christoph Hellwig
2021-03-17 16:59 ` Christoph Hellwig
2021-03-17 17:21 ` Jens Axboe
2021-03-17 17:21 ` Jens Axboe
2021-03-17 18:59 ` Jens Axboe
2021-03-17 18:59 ` Jens Axboe
2021-03-18 5:54 ` Kanchan Joshi
2021-03-18 5:54 ` Kanchan Joshi
2021-03-17 16:45 ` Keith Busch
2021-03-17 16:45 ` Keith Busch
2021-03-17 17:02 ` Christoph Hellwig
2021-03-17 17:02 ` Christoph Hellwig
2021-03-16 15:51 ` [RFC PATCH v3 0/3] Async nvme passthrough over io_uring Jens Axboe
2021-03-16 15:51 ` Jens Axboe
2021-03-17 9:31 ` Kanchan Joshi
2021-03-17 9:31 ` Kanchan Joshi
2021-03-18 1:58 ` Jens Axboe
2021-03-18 1:58 ` Jens Axboe
2021-03-18 7:47 ` Kanchan Joshi
2021-03-18 7:47 ` 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 \
--in-reply-to=20210317085258.GA19580@lst.de \
--to=hch@lst.de \
--cc=anuj20.g@samsung.com \
--cc=axboe@kernel.dk \
--cc=chaitanya.kulkarni@wdc.com \
--cc=io-uring@vger.kernel.org \
--cc=javier.gonz@samsung.com \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nj.shetty@samsung.com \
--cc=selvakuma.s1@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 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.