Re: [PATCH] block/io_uring: pass in issue_flags for uring_cmd task_work handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 21, 2023 at 7:37 AM Jens Axboe <axboe@xxxxxxxxx> wrote:
>
> io_uring_cmd_done() currently assumes that the uring_lock is held
> when invoked, and while it generally is, this is not guaranteed.
> Pass in the issue_flags associated with it, so that we have
> IO_URING_F_UNLOCKED available to be able to lock the CQ ring
> appropriately when completing events.
>
> Cc: stable@xxxxxxxxxxxxxxx
> Fixes: ee692a21e9bf ("fs,io_uring: add infrastructure for uring-cmd")

While the ability to pass flags seems useful, I am trying to
understand if the tag 'fixes' is a must?
Before this patch, the F_UNLOCKED flag was not used and completions go
to line 1006 (please see below).
After this patch also, completions execute the same code as IOPOLL is not set.
In both cases, ctx->completion_lock is being acquired while posting completions.
And for polled passthrough IOs, we don't execute this code anway.

999 void io_req_complete_post(struct io_kiocb *req, unsigned issue_flags)
1000 {
1001         if (req->ctx->task_complete && (issue_flags & IO_URING_F_IOWQ)) {
1002                 req->io_task_work.func = io_req_task_complete;
1003                 io_req_task_work_add(req);
1004         } else if (!(issue_flags & IO_URING_F_UNLOCKED) ||
1005                    !(req->ctx->flags & IORING_SETUP_IOPOLL)) {
1006                 __io_req_complete_post(req);
1007         } else {
1008                 struct io_ring_ctx *ctx = req->ctx;
1009
1010                 mutex_lock(&ctx->uring_lock);
1011                 __io_req_complete_post(req);




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux