From: Ming Lei <tom.leiming@gmail.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org,
Caleb Sander Mateos <csander@purestorage.com>,
Uday Shankar <ushankar@purestorage.com>
Subject: Re: [PATCH] ublk: reject FETCH from non-userspace context
Date: Fri, 1 May 2026 18:54:53 +0800 [thread overview]
Message-ID: <afSGfdcmtKHpvR07@fedora> (raw)
In-Reply-To: <c97fe4d3-9b48-4793-a008-4fbf7e72f5b0@kernel.dk>
On Fri, May 01, 2026 at 04:38:22AM -0600, Jens Axboe wrote:
> On 5/1/26 4:36 AM, Ming Lei wrote:
> > On Fri, May 01, 2026 at 04:34:11AM -0600, Jens Axboe wrote:
> >> On 5/1/26 2:52 AM, Ming Lei wrote:
> >>> __ublk_fetch() sets io->task to current, which is later checked
> >>> against io_uring_cmd_get_task() in ublk_uring_cmd_cancel_fn().
> >>> With REQ_F_FORCE_ASYNC, the FETCH uring_cmd can be issued from
> >>> task work, which can be run from io_uring's fallback workqueue,
> >>> causing a task mismatch and triggering the WARN in cancel_fn.
> >>>
> >>> Reject FETCH if current is not a real userspace task, and it is
> >>> reasonable for failing it in case of io_uring fallback.
> >>
> >> I think this should be caught in ublk_ch_uring_cmd_cb(), which
> >> should not hit ublk_ch_uring_cmd_local() if tw.cancel is true.
> >> fallback work should just be terminated, not be issued.
> >
> > Yeah, that is definitely better, will take it in V2.
>
> Something like this, totally untested. Caveat: probably worth checking
> the other tw paths in ublk as well!
tw.cancel can replace the check in ublk_dispatch_req() for ublk_cmd_tw_cb() and
ublk_cmd_list_tw_cb(), which is one cleanup.
ublk_batch_tw_cb() doesn't track io task, so it is just fine.
>
> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> index 8e5f3738c203..d10460d29e4a 100644
> --- a/drivers/block/ublk_drv.c
> +++ b/drivers/block/ublk_drv.c
> @@ -3496,8 +3496,10 @@ static void ublk_ch_uring_cmd_cb(struct io_tw_req tw_req, io_tw_token_t tw)
> {
> unsigned int issue_flags = IO_URING_CMD_TASK_WORK_ISSUE_FLAGS;
> struct io_uring_cmd *cmd = io_uring_cmd_from_tw(tw_req);
> - int ret = ublk_ch_uring_cmd_local(cmd, issue_flags);
> + int ret = -ECANCELED;
>
> + if (!tw.cancel)
> + ret = ublk_ch_uring_cmd_local(cmd, issue_flags);
> if (ret != -EIOCBQUEUED)
> io_uring_cmd_done(cmd, ret, issue_flags);
> }
This fix looks good.
Thanks,
Ming
next prev parent reply other threads:[~2026-05-01 10:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 8:52 [PATCH] ublk: reject FETCH from non-userspace context Ming Lei
2026-05-01 10:34 ` Jens Axboe
2026-05-01 10:36 ` Ming Lei
2026-05-01 10:38 ` Jens Axboe
2026-05-01 10:54 ` Ming Lei [this message]
2026-05-01 11:05 ` Jens Axboe
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=afSGfdcmtKHpvR07@fedora \
--to=tom.leiming@gmail.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.