aboutsummaryrefslogtreecommitdiffstats
path: root/kernel/signal.c
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2021-01-05 11:32:43 -0700
committerJens Axboe <axboe@kernel.dk>2021-01-08 09:14:21 -0700
commit35d0b389f3b23439ad15b610d6e43fc72fc75779 (patch)
tree0db600fd2906e728692e0788874e2df3823b7a00 /kernel/signal.c
parente71ba9452f0b5b2e8dc8aa5445198cd9214a6a62 (diff)
downloadlinux-35d0b389f3b23439ad15b610d6e43fc72fc75779.tar.gz
task_work: unconditionally run task_work from get_signal()
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>
Diffstat (limited to 'kernel/signal.c')
-rw-r--r--kernel/signal.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/kernel/signal.c b/kernel/signal.c
index 5736c55aaa1af..6b9c431da08fe 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2550,6 +2550,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