summaryrefslogtreecommitdiffstats
path: root/fs/cachefiles
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2021-01-19 22:26:05 +0100
committerLinus Torvalds <torvalds@linux-foundation.org>2021-01-19 22:26:05 +0100
commit45dfb8a5659ad286c28fa59008271dbc4e5e3f2d (patch)
tree166f3b3f97417d9d17871e241c9fad4ee36bdc14 /fs/cachefiles
parentMerge tag 'nfsd-5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/... (diff)
parenttask_work: unconditionally run task_work from get_signal() (diff)
downloadlinux-45dfb8a5659ad286c28fa59008271dbc4e5e3f2d.tar.xz
linux-45dfb8a5659ad286c28fa59008271dbc4e5e3f2d.zip
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