Pull task_work fix from Jens Axboe: "The TIF_NOTIFY_SIGNAL change inadvertently removed the unconditional task_work run we had in get_signal(). This caused a regression for some setups, since we're relying on eg ____fput() being run to close and release, for example, a pipe and wake the other end. For 5.11, I prefer the simple solution of just reinstating the unconditional run, even if it conceptually doesn't make much sense - if you need that kind of guarantee, you should be using TWA_SIGNAL instead of TWA_NOTIFY. But it's the trivial fix for 5.11, and would ensure that other potential gotchas/assumptions for task_work don't regress for 5.11. We're looking into further simplifying the task_work notifications for 5.12 which would resolve that too" * tag 'task_work-2021-01-19' of git://git.kernel.dk/linux-block: task_work: unconditionally run task_work from get_signal()
Unified · Split
| @@ -2550,6 +2550,9 @@ bool get_signal(struct ksignal *ksig) · 2549 unmodified lines | ||
| 2550 | 2550 | struct signal_struct *signal = current->signal; |
| 2551 | 2551 | int signr; |
| 2552 | 2552 | |
| 2553 | + if (unlikely(current->task_works)) | |
| 2554 | + task_work_run(); | |
| 2555 | + | |
| 2553 | 2556 | /* |
| 2554 | 2557 | * For non-generic architectures, check for TIF_NOTIFY_SIGNAL so |
| 2555 | 2558 | * that the arch handlers don't all have to do it. If we get here |