Al Viro 275655d320 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>
2024-02-25 02:10:31 -05:00
..
2024-01-11 20:11:35 -08:00
2024-01-11 13:58:04 -08:00
2024-01-19 09:10:23 -08:00
2024-01-11 20:11:35 -08:00
2023-10-30 09:47:13 -10:00
2023-11-07 12:11:26 -08:00
2024-01-19 09:10:23 -08:00
2023-11-07 12:11:26 -08:00
2024-01-08 11:11:51 -08:00
2024-01-10 10:17:23 -08:00
2023-12-29 11:58:34 -08:00
2024-01-10 17:44:36 -08:00
2024-01-19 09:10:23 -08:00
2024-01-19 09:10:23 -08:00
2024-01-11 20:11:35 -08:00
2024-01-10 17:44:36 -08:00
2023-11-07 12:11:26 -08:00
2024-01-11 20:11:35 -08:00
2024-01-10 17:44:36 -08:00
2023-10-30 09:47:13 -10:00
2024-01-06 23:49:50 +01:00
2024-01-11 10:07:29 -08:00
2024-01-19 09:57:08 -08:00
2024-01-10 17:44:36 -08:00
2023-12-21 13:17:54 +01:00
2023-10-30 19:28:19 -10:00
2023-10-30 19:28:19 -10:00
2024-01-11 20:11:35 -08:00
2024-01-11 20:11:35 -08:00
2023-12-12 14:24:14 +01:00
2024-01-11 20:00:22 -08:00
2024-01-11 20:11:35 -08:00
2024-01-19 09:10:23 -08:00
2024-01-11 20:11:35 -08:00
2024-01-19 09:10:23 -08:00
2023-11-25 02:49:43 -05:00
2024-01-08 11:11:51 -08:00
2024-01-10 17:44:36 -08:00
2024-01-08 10:57:34 -08:00
2024-01-17 13:03:37 -08:00