diff options
| author | Al Viro <[email protected]> | 2018-05-24 02:53:22 +0000 |
|---|---|---|
| committer | Al Viro <[email protected]> | 2018-05-24 02:53:22 +0000 |
| commit | 4faa99965e027cc057c5145ce45fa772caa04e8d (patch) | |
| tree | 5c0c1e8d18e1a4f0964fe8b40e343ecd9cfbada8 /fs/proc/array.c | |
| parent | aio: fix io_destroy(2) vs. lookup_ioctx() race (diff) | |
| download | kernel-4faa99965e027cc057c5145ce45fa772caa04e8d.tar.gz kernel-4faa99965e027cc057c5145ce45fa772caa04e8d.zip | |
fix io_destroy()/aio_complete() race
If io_destroy() gets to cancelling everything that can be cancelled and
gets to kiocb_cancel() calling the function driver has left in ->ki_cancel,
it becomes vulnerable to a race with IO completion. At that point req
is already taken off the list and aio_complete() does *NOT* spin until
we (in free_ioctx_users()) releases ->ctx_lock. As the result, it proceeds
to kiocb_free(), freing req just it gets passed to ->ki_cancel().
Fix is simple - remove from the list after the call of kiocb_cancel(). All
instances of ->ki_cancel() already have to cope with the being called with
iocb still on list - that's what happens in io_cancel(2).
Cc: [email protected]
Fixes: 0460fef2a921 "aio: use cancellation list lazily"
Signed-off-by: Al Viro <[email protected]>
Diffstat (limited to 'fs/proc/array.c')
0 files changed, 0 insertions, 0 deletions
