This is a note to let you know that I've just added the patch titled
io_uring/net: cache provided buffer group value for multishot receives
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
io_uring-net-cache-provided-buffer-group-value-for-multishot-receives.patch
and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From b00c51ef8f72ced0965d021a291b98ff822c5337 Mon Sep 17 00:00:00 2001
From: Jens Axboe <axboe@xxxxxxxxx>
Date: Sun, 22 Jan 2023 10:02:55 -0700
Subject: io_uring/net: cache provided buffer group value for multishot receives
From: Jens Axboe <axboe@xxxxxxxxx>
commit b00c51ef8f72ced0965d021a291b98ff822c5337 upstream.
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@xxxxxxxxxxxxxxx
Fixes: b3fdea6ecb55 ("io_uring: multishot recv")
Fixes: 9bb66906f23e ("io_uring: support multishot in recvmsg")
Cc: Dylan Yudaken <dylany@xxxxxxxx>
Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
io_uring/net.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/io_uring/net.c
+++ b/io_uring/net.c
@@ -62,6 +62,7 @@ struct io_sr_msg {
u16 flags;
/* initialised and used only by !msg send variants */
u16 addr_len;
+ u16 buf_group;
void __user *addr;
/* used only for send zerocopy */
struct io_kiocb *notif;
@@ -565,6 +566,15 @@ int io_recvmsg_prep(struct io_kiocb *req
if (req->opcode == IORING_OP_RECV && sr->len)
return -EINVAL;
req->flags |= REQ_F_APOLL_MULTISHOT;
+ /*
+ * Store the buffer group for this multishot receive separately,
+ * as if we end up doing an io-wq based issue that selects a
+ * buffer, it has to be committed immediately and that will
+ * clear ->buf_list. This means we lose the link to the buffer
+ * list, and the eventual buffer put on completion then cannot
+ * restore it.
+ */
+ sr->buf_group = req->buf_index;
}
#ifdef CONFIG_COMPAT
@@ -581,6 +591,7 @@ static inline void io_recv_prep_retry(st
sr->done_io = 0;
sr->len = 0; /* get from the provided buffer */
+ req->buf_index = sr->buf_group;
}
/*
Patches currently in stable-queue which might be from axboe@xxxxxxxxx are
queue-6.1/io_uring-msg_ring-fix-remote-queue-to-disabled-ring.patch
queue-6.1/block-rnbd-clt-fix-wrong-max-id-in-ida_alloc_max.patch
queue-6.1/io_uring-net-cache-provided-buffer-group-value-for-multishot-receives.patch
queue-6.1/blk-crypto-pass-a-gendisk-to-blk_crypto_sysfs_-un-re.patch
queue-6.1/block-drop-spurious-might_sleep-from-blk_put_queue.patch
queue-6.1/block-mark-blk_put_queue-as-potentially-blocking.patch
queue-6.1/block-factor-out-a-blk_debugfs_remove-helper.patch
queue-6.1/block-fix-error-unwinding-in-blk_register_queue.patch
queue-6.1/block-untangle-request_queue-refcounting-from-sysfs.patch
queue-6.1/blk-mq-move-the-srcu_struct-used-for-quiescing-to-th.patch
