public inbox for [email protected]
 help / color / mirror / Atom feed
From: Luis Chamberlain <[email protected]>
To: Jens Axboe <[email protected]>
Cc: "Kanchan Joshi" <[email protected]>,
	"Kanchan Joshi" <[email protected]>,
	[email protected], [email protected],
	[email protected], "Christoph Hellwig" <[email protected]>,
	"Keith Busch" <[email protected]>,
	"Javier González" <[email protected]>,
	"Anuj Gupta" <[email protected]>,
	"Pankaj Raghav" <[email protected]>
Subject: Re: [RFC 01/13] io_uring: add infra for uring_cmd completion in submitter-task
Date: Thu, 17 Feb 2022 09:56:37 -0800	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On Thu, Feb 17, 2022 at 08:50:59AM -0700, Jens Axboe wrote:
> On 2/17/22 8:39 AM, Kanchan Joshi wrote:
> > On Thu, Feb 17, 2022 at 7:43 AM Luis Chamberlain <[email protected]> wrote:
> >>
> >> On Mon, Dec 20, 2021 at 07:47:22PM +0530, Kanchan Joshi wrote:
> >>> Completion of a uring_cmd ioctl may involve referencing certain
> >>> ioctl-specific fields, requiring original submitter context.
> >>> Export an API that driver can use for this purpose.
> >>> The API facilitates reusing task-work infra of io_uring, while driver
> >>> gets to implement cmd-specific handling in a callback.
> >>>
> >>> Signed-off-by: Kanchan Joshi <[email protected]>
> >>> Signed-off-by: Anuj Gupta <[email protected]>
> >>> ---
> >>>  fs/io_uring.c            | 16 ++++++++++++++++
> >>>  include/linux/io_uring.h |  8 ++++++++
> >>>  2 files changed, 24 insertions(+)
> >>>
> >>> diff --git a/fs/io_uring.c b/fs/io_uring.c
> >>> index e96ed3d0385e..246f1085404d 100644
> >>> --- a/fs/io_uring.c
> >>> +++ b/fs/io_uring.c
> >>> @@ -2450,6 +2450,22 @@ static void io_req_task_submit(struct io_kiocb *req, bool *locked)
> >>>               io_req_complete_failed(req, -EFAULT);
> >>>  }
> >>>
> >>> +static void io_uring_cmd_work(struct io_kiocb *req, bool *locked)
> >>> +{
> >>> +     req->uring_cmd.driver_cb(&req->uring_cmd);
> >>
> >> If the callback memory area is gone, boom.
> > 
> > Why will the memory area be gone?
> > Module removal is protected because try_module_get is done anyway when
> > the namespace was opened.
> 
> And the req isn't going away before it's completed.

Groovy, it would be nice to add a little /* comment */ to just remind
the reader?

> >>> +{
> >>> +     struct io_kiocb *req = container_of(ioucmd, struct io_kiocb, uring_cmd);
> >>> +
> >>> +     req->uring_cmd.driver_cb = driver_cb;
> >>> +     req->io_task_work.func = io_uring_cmd_work;
> >>> +     io_req_task_work_add(req, !!(req->ctx->flags & IORING_SETUP_SQPOLL));
> >>
> >> This can schedules, and so the callback may go fishing in the meantime.
> > 
> > io_req_task_work_add is safe to be called in atomic context. FWIW,
> > io_uring uses this for regular (i.e. direct block) io completion too.
> 
> Correct, it doesn't schedule and is safe from irq context as long as the
> task is pinned (which it is, via the req itself).

Great, a kdoc explaining the routine and that it can be called from
atomic context and the rationale would be very useful to users. And ..
so the callback *must* be safe in atomic context too or can it sleep?

  Luis

  reply	other threads:[~2022-02-17 17:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20211220142227epcas5p280851b0a62baa78379979eb81af7a096@epcas5p2.samsung.com>
2021-12-20 14:17 ` [RFC 00/13] uring-passthru for nvme Kanchan Joshi
     [not found]   ` <CGME20211220142228epcas5p2978d92d38f2015148d5f72913d6dbc3e@epcas5p2.samsung.com>
2021-12-20 14:17     ` [RFC 01/13] io_uring: add infra for uring_cmd completion in submitter-task Kanchan Joshi
2022-02-17  2:13       ` Luis Chamberlain
2022-02-17 15:39         ` Kanchan Joshi
2022-02-17 15:50           ` Jens Axboe
2022-02-17 17:56             ` Luis Chamberlain [this message]
2022-02-18 17:41               ` Kanchan Joshi
2022-02-17 18:46             ` Luis Chamberlain
2022-02-17 18:53               ` Jens Axboe
     [not found]   ` <CGME20211220142231epcas5p1482c78f91feabdbc3e62341790ab22e1@epcas5p1.samsung.com>
2021-12-20 14:17     ` [RFC 02/13] nvme: wire-up support for async-passthru on char-device Kanchan Joshi
     [not found]   ` <CGME20211220142233epcas5p3b54aa591fb7b81bfb58bc33b5f92a2d3@epcas5p3.samsung.com>
2021-12-20 14:17     ` [RFC 03/13] io_uring: mark iopoll not supported for uring-cmd Kanchan Joshi
2022-02-17  2:16       ` Luis Chamberlain
2022-02-17  2:52         ` Jens Axboe
     [not found]   ` <CGME20211220142235epcas5p3b8d56cd39d9710278ec3360be47f2cca@epcas5p3.samsung.com>
2021-12-20 14:17     ` [RFC 04/13] io_uring: modify unused field in io_uring_cmd to store flags Kanchan Joshi
     [not found]   ` <CGME20211220142237epcas5p48729a52293e4f7627e6ec53ca67b9c58@epcas5p4.samsung.com>
2021-12-20 14:17     ` [RFC 05/13] io_uring: add flag and helper for fixed-buffer uring-cmd Kanchan Joshi
     [not found]   ` <CGME20211220142239epcas5p3efc3c89bd536f3f5d728c81bc550e143@epcas5p3.samsung.com>
2021-12-20 14:17     ` [RFC 06/13] io_uring: add support for uring_cmd with fixed-buffer Kanchan Joshi
     [not found]   ` <CGME20211220142242epcas5p45dddab51a9f20a8ec3d8b8e4f1dda40a@epcas5p4.samsung.com>
2021-12-20 14:17     ` [RFC 07/13] nvme: enable passthrough " Kanchan Joshi
     [not found]   ` <CGME20211220142244epcas5p2f311ed168b8f31b9301bcc2002076db4@epcas5p2.samsung.com>
2021-12-20 14:17     ` [RFC 08/13] io_uring: plug for async bypass Kanchan Joshi
     [not found]   ` <CGME20211220142246epcas5p303c64b6b1b832c7fcd5ac31fc79c91d1@epcas5p3.samsung.com>
2021-12-20 14:17     ` [RFC 09/13] block: wire-up support for plugging Kanchan Joshi
     [not found]   ` <CGME20211220142248epcas5p1e5904e10396f8cdea54bbd8d7aeca9a6@epcas5p1.samsung.com>
2021-12-20 14:17     ` [RFC 10/13] block: factor out helper for bio allocation from cache Kanchan Joshi
     [not found]   ` <CGME20211220142250epcas5p34b9d93b1dd3388af6209a4223befe40f@epcas5p3.samsung.com>
2021-12-20 14:17     ` [RFC 11/13] nvme: enable bio-cache for fixed-buffer passthru Kanchan Joshi
     [not found]   ` <CGME20211220142252epcas5p4611297f9970acbc8ee3b0e325ca5ceec@epcas5p4.samsung.com>
2021-12-20 14:17     ` [RFC 12/13] nvme: allow user passthrough commands to poll Kanchan Joshi
     [not found]   ` <CGME20211220142256epcas5p49e0804ff8b075e8063259f94ccc9ced0@epcas5p4.samsung.com>
2021-12-20 14:17     ` [RFC 13/13] nvme: Add async passthru polling support Kanchan Joshi
2021-12-21  3:45   ` [RFC 00/13] uring-passthru for nvme Jens Axboe
2021-12-21 14:36     ` 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] \
    [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