From: Jens Axboe axboe@kernel.dk
[ 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 Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- kernel/signal.c | 3 +++ 1 file changed, 3 insertions(+)
--- a/kernel/signal.c +++ b/kernel/signal.c @@ -2520,6 +2520,9 @@ bool get_signal(struct ksignal *ksig) struct signal_struct *signal = current->signal; int signr;
+ if (unlikely(current->task_works)) + task_work_run(); + /* * For non-generic architectures, check for TIF_NOTIFY_SIGNAL so * that the arch handlers don't all have to do it. If we get here