task_work: unconditionally run task_work from get_signal()
authorJens Axboe <axboe@kernel.dk>
Tue, 5 Jan 2021 18:32:43 +0000 (11:32 -0700)
committerJens Axboe <axboe@kernel.dk>
Fri, 23 Dec 2022 21:51:22 +0000 (14:51 -0700)
commit0f315fd4143c1591a7f902fa08b71b83764f4fa0
tree568864b7a65e058bdae17df6637917544c4a44ea
parent450fb0845804e4245b90eb155d7ac34cda11429f
task_work: unconditionally run task_work from get_signal()

[ Upstream commit 35d0b389f3b23439ad15b610d6e43fc72fc75779 ]

Song reported a boot regression in a kvm image with 5.11-rc, and bisected
it down to the below patch. Debugging this issue, turns out that the boot
stalled when a task is waiting on a pipe being released. As we no longer
run task_work from get_signal() unless it's queued with TWA_SIGNAL, the
task goes idle without running the task_work. This prevents ->release()
from being called on the pipe, which another boot task is waiting on.

For now, re-instate the unconditional task_work run from get_signal().
For 5.12, we'll collapse TWA_RESUME and TWA_SIGNAL, as it no longer
makes sense to have a distinction between the two. This will turn
task_work notification into a simple boolean, whether to notify or not.

Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK")
Reported-by: Song Liu <songliubraving@fb.com>
Tested-by: John Stultz <john.stultz@linaro.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang version 11.0.1
Signed-off-by: Jens Axboe <axboe@kernel.dk>
kernel/signal.c