diff options
author | Al Viro <viro@zeniv.linux.org.uk> | 2023-09-29 20:24:34 -0400 |
---|---|---|
committer | Al Viro <viro@zeniv.linux.org.uk> | 2024-02-25 02:10:31 -0500 |
commit | 275655d3207b9e65d1561bf21c06a622d9ec1d43 (patch) | |
tree | a57f17b452a230ede597dc2d9bbed33e597e99f0 /fs/afs/flock.c | |
parent | af072cf683acd2307e02378cfcf2502c49d2e127 (diff) | |
download | linux-275655d3207b9e65d1561bf21c06a622d9ec1d43.tar.gz linux-275655d3207b9e65d1561bf21c06a622d9ec1d43.tar.bz2 linux-275655d3207b9e65d1561bf21c06a622d9ec1d43.zip |
afs: fix __afs_break_callback() / afs_drop_open_mmap() race
In __afs_break_callback() we might check ->cb_nr_mmap and if it's non-zero
do queue_work(&vnode->cb_work). In afs_drop_open_mmap() we decrement
->cb_nr_mmap and do flush_work(&vnode->cb_work) if it reaches zero.
The trouble is, there's nothing to prevent __afs_break_callback() from
seeing ->cb_nr_mmap before the decrement and do queue_work() after both
the decrement and flush_work(). If that happens, we might be in trouble -
vnode might get freed before the queued work runs.
__afs_break_callback() is always done under ->cb_lock, so let's make
sure that ->cb_nr_mmap can change from non-zero to zero while holding
->cb_lock (the spinlock component of it - it's a seqlock and we don't
need to mess with the counter).
Acked-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'fs/afs/flock.c')
0 files changed, 0 insertions, 0 deletions