summaryrefslogtreecommitdiffstats
path: root/kernel/cgroup
diff options
context:
space:
mode:
authorNadav Amit <namit@vmware.com>2021-08-07 17:13:41 -0700
committerJens Axboe <axboe@kernel.dk>2021-08-08 21:21:11 -0600
commitef98eb0409c31c39ab55ff46b2721c3b4f84c122 (patch)
tree931e4d26e6efd78bab25b83d05c1ab85494296b6 /kernel/cgroup
parent21698274da5b6fc724b005bc7ec3e6b9fbcfaa06 (diff)
downloadlinux-stable-ef98eb0409c31c39ab55ff46b2721c3b4f84c122.tar.gz
linux-stable-ef98eb0409c31c39ab55ff46b2721c3b4f84c122.tar.bz2
linux-stable-ef98eb0409c31c39ab55ff46b2721c3b4f84c122.zip
io_uring: clear TIF_NOTIFY_SIGNAL when running task work
When using SQPOLL, the submission queue polling thread calls task_work_run() to run queued work. However, when work is added with TWA_SIGNAL - as done by io_uring itself - the TIF_NOTIFY_SIGNAL remains set afterwards and is never cleared. Consequently, when the submission queue polling thread checks whether signal_pending(), it may always find a pending signal, if task_work_add() was ever called before. The impact of this bug might be different on different kernel versions. It appears that on 5.14 it would only cause unnecessary calculation and prevent the polling thread from sleeping. On 5.13, where the bug was found, it stops the polling thread from finding newly submitted work. Instead of task_work_run(), use tracehook_notify_signal() that clears TIF_NOTIFY_SIGNAL. Test for TIF_NOTIFY_SIGNAL in addition to current->task_works to avoid a race in which task_works is cleared but the TIF_NOTIFY_SIGNAL is set. Fixes: 685fe7feedb96 ("io-wq: eliminate the need for a manager thread") Cc: Jens Axboe <axboe@kernel.dk> Cc: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Nadav Amit <namit@vmware.com> Link: https://lore.kernel.org/r/20210808001342.964634-2-namit@vmware.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'kernel/cgroup')
0 files changed, 0 insertions, 0 deletions