diff options
author | Jens Axboe <axboe@kernel.dk> | 2021-07-23 11:49:29 -0600 |
---|---|---|
committer | Jens Axboe <axboe@kernel.dk> | 2021-07-23 16:32:48 -0600 |
commit | 3c30ef0f78cfb36fdb13753794b0384cf7e37cc9 (patch) | |
tree | 902e647af4228ab69e528555877c3919a79d0655 /fs/io-wq.c | |
parent | 0cc936f74bcacb039b7533aeac0a887dfc896bf6 (diff) | |
download | linux-3c30ef0f78cfb36fdb13753794b0384cf7e37cc9.tar.gz linux-3c30ef0f78cfb36fdb13753794b0384cf7e37cc9.tar.bz2 linux-3c30ef0f78cfb36fdb13753794b0384cf7e37cc9.zip |
io_uring: never attempt iopoll reissue from release path
There are two reasons why this shouldn't be done:
1) Ring is exiting, and we're canceling requests anyway. Any request
should be canceled anyway. In theory, this could iterate for a
number of times if someone else is also driving the target block
queue into request starvation, however the likelihood of this
happening is miniscule.
2) If the original task decided to pass the ring to another task, then
we don't want to be reissuing from this context as it may be an
unrelated task or context. No assumptions should be made about
the context in which ->release() is run. This can only happen for pure
read/write, and we'll get -EFAULT on them anyway.
Link: https://lore.kernel.org/io-uring/YPr4OaHv0iv0KTOc@zeniv-ca.linux.org.uk/
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'fs/io-wq.c')
0 files changed, 0 insertions, 0 deletions