summaryrefslogtreecommitdiffstats
path: root/io_uring/io_uring.c
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2023-01-22 10:02:55 -0700
committerJens Axboe <axboe@kernel.dk>2023-01-23 07:08:08 -0700
commitb00c51ef8f72ced0965d021a291b98ff822c5337 (patch)
tree4bfa44d6e61e20fdb885bb9c6cf4daa052e73a8a /io_uring/io_uring.c
parent8caa03f10bf92cb8657408a6ece6a8a73f96ce13 (diff)
downloadlinux-b00c51ef8f72ced0965d021a291b98ff822c5337.tar.bz2
io_uring/net: cache provided buffer group value for multishot receives
If we're using ring provided buffers with multishot receive, and we end up doing an io-wq based issue at some points that also needs to select a buffer, we'll lose the initially assigned buffer group as io_ring_buffer_select() correctly clears the buffer group list as the issue isn't serialized by the ctx uring_lock. This is fine for normal receives as the request puts the buffer and finishes, but for multishot, we will re-arm and do further receives. On the next trigger for this multishot receive, the receive will try and pick from a buffer group whose value is the same as the buffer ID of the las receive. That is obviously incorrect, and will result in a premature -ENOUFS error for the receive even if we had available buffers in the correct group. Cache the buffer group value at prep time, so we can restore it for future receives. This only needs doing for the above mentioned case, but just do it by default to keep it easier to read. Cc: stable@vger.kernel.org Fixes: b3fdea6ecb55 ("io_uring: multishot recv") Fixes: 9bb66906f23e ("io_uring: support multishot in recvmsg") Cc: Dylan Yudaken <dylany@meta.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'io_uring/io_uring.c')
0 files changed, 0 insertions, 0 deletions