diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2021-01-20 00:26:05 +0300 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2021-01-20 00:26:05 +0300 |
commit | 45dfb8a5659ad286c28fa59008271dbc4e5e3f2d (patch) | |
tree | 166f3b3f97417d9d17871e241c9fad4ee36bdc14 /fs/cachefiles | |
parent | f419f031de1498765b64ddf71590f40689a9b55c (diff) | |
parent | 35d0b389f3b23439ad15b610d6e43fc72fc75779 (diff) | |
download | linux-45dfb8a5659ad286c28fa59008271dbc4e5e3f2d.tar.xz |
Merge tag 'task_work-2021-01-19' of git://git.kernel.dk/linux-block
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()
Diffstat (limited to 'fs/cachefiles')
0 files changed, 0 insertions, 0 deletions