diff options
author | Jens Axboe <axboe@kernel.dk> | 2023-01-22 10:02:55 -0700 |
---|---|---|
committer | Jens Axboe <axboe@kernel.dk> | 2023-01-23 07:08:08 -0700 |
commit | b00c51ef8f72ced0965d021a291b98ff822c5337 (patch) | |
tree | 4bfa44d6e61e20fdb885bb9c6cf4daa052e73a8a /io_uring/io_uring.c | |
parent | 8caa03f10bf92cb8657408a6ece6a8a73f96ce13 (diff) | |
download | linux-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