summaryrefslogtreecommitdiffstats
path: root/fs/jffs2/writev.c
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2021-03-01 13:56:00 -0700
committerJens Axboe <axboe@kernel.dk>2021-03-04 06:38:01 -0700
commit3e6a0d3c7571ce3ed0d25c5c32543a54a7ebcd75 (patch)
treeff7601dcfcfacd23d47a45ec0fed2f0548fa5bf5 /fs/jffs2/writev.c
parentdc7bbc9ef361bea331bf5258a35abcdef619d44d (diff)
downloadlinux-stable-3e6a0d3c7571ce3ed0d25c5c32543a54a7ebcd75.tar.gz
linux-stable-3e6a0d3c7571ce3ed0d25c5c32543a54a7ebcd75.tar.bz2
linux-stable-3e6a0d3c7571ce3ed0d25c5c32543a54a7ebcd75.zip
io_uring: fix -EAGAIN retry with IOPOLL
We no longer revert the iovec on -EIOCBQUEUED, see commit ab2125df921d, and this started causing issues for IOPOLL on devies that run out of request slots. Turns out what outside of needing a revert for those, we also had a bug where we didn't properly setup retry inside the submission path. That could cause re-import of the iovec, if any, and that could lead to spurious results if the application had those allocated on the stack. Catch -EAGAIN retry and make the iovec stable for IOPOLL, just like we do for !IOPOLL retries. Cc: <stable@vger.kernel.org> # 5.9+ Reported-by: Abaci Robot <abaci@linux.alibaba.com> Reported-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'fs/jffs2/writev.c')
0 files changed, 0 insertions, 0 deletions