summaryrefslogtreecommitdiffstats
path: root/fs/cifs/file.c
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2020-06-30 12:39:05 -0600
committerJens Axboe <axboe@kernel.dk>2020-06-30 12:39:05 -0600
commitce593a6c480a22acba08795be313c0c6d49dd35d (patch)
treea31b7d4e964ada0b9b768d405507c699dfef91b4 /fs/cifs/file.c
parente91b48162332480f5840902268108bb7fb7a44c7 (diff)
downloadlinux-ce593a6c480a22acba08795be313c0c6d49dd35d.tar.bz2
io_uring: use signal based task_work running
Since 5.7, we've been using task_work to trigger async running of requests in the context of the original task. This generally works great, but there's a case where if the task is currently blocked in the kernel waiting on a condition to become true, it won't process task_work. Even though the task is woken, it just checks whatever condition it's waiting on, and goes back to sleep if it's still false. This is a problem if that very condition only becomes true when that task_work is run. An example of that is the task registering an eventfd with io_uring, and it's now blocked waiting on an eventfd read. That read could depend on a completion event, and that completion event won't get trigged until task_work has been run. Use the TWA_SIGNAL notification for task_work, so that we ensure that the task always runs the work when queued. Cc: stable@vger.kernel.org # v5.7 Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'fs/cifs/file.c')
0 files changed, 0 insertions, 0 deletions