* [PATCH v2 1/1] io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with MSG_WAITALL
2021-03-16 15:33 [PATCH 1/2] io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() calls Stefan Metzmacher
@ 2021-03-20 19:33 ` Stefan Metzmacher
2021-03-20 22:57 ` Jens Axboe
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Metzmacher @ 2021-03-20 19:33 UTC (permalink / raw
To: io-uring; +Cc: Stefan Metzmacher, netdev
Without that it's not safe to use them in a linked combination with
others.
Now combinations like IORING_OP_SENDMSG followed by IORING_OP_SPLICE
should be possible.
We already handle short reads and writes for the following opcodes:
- IORING_OP_READV
- IORING_OP_READ_FIXED
- IORING_OP_READ
- IORING_OP_WRITEV
- IORING_OP_WRITE_FIXED
- IORING_OP_WRITE
- IORING_OP_SPLICE
- IORING_OP_TEE
Now we have it for these as well:
- IORING_OP_SENDMSG
- IORING_OP_SEND
- IORING_OP_RECVMSG
- IORING_OP_RECV
For IORING_OP_RECVMSG we also check for the MSG_TRUNC and MSG_CTRUNC
flags in order to call req_set_fail_links().
There might be applications arround depending on the behavior
that even short send[msg]()/recv[msg]() retuns continue an
IOSQE_IO_LINK chain.
It's very unlikely that such applications pass in MSG_WAITALL,
which is only defined in 'man 2 recvmsg', but not in 'man 2 sendmsg'.
It's expected that the low level sock_sendmsg() call just ignores
MSG_WAITALL, as MSG_ZEROCOPY is also ignored without explicitly set
SO_ZEROCOPY.
We also expect the caller to know about the implicit truncation to
MAX_RW_COUNT, which we don't detect.
cc: netdev@vger.kernel.org
Link: https://lore.kernel.org/r/c4e1a4cc0d905314f4d5dc567e65a7b09621aab3.1615908477.git.metze@samba.org
Signed-off-by: Stefan Metzmacher <metze@samba.org>
---
fs/io_uring.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 75b791ff21ec..746435e3f534 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -4386,6 +4386,7 @@ static int io_sendmsg(struct io_kiocb *req, unsigned int issue_flags)
struct io_async_msghdr iomsg, *kmsg;
struct socket *sock;
unsigned flags;
+ int min_ret = 0;
int ret;
sock = sock_from_file(req->file);
@@ -4406,6 +4407,9 @@ static int io_sendmsg(struct io_kiocb *req, unsigned int issue_flags)
else if (issue_flags & IO_URING_F_NONBLOCK)
flags |= MSG_DONTWAIT;
+ if (flags & MSG_WAITALL)
+ min_ret = iov_iter_count(&kmsg->msg.msg_iter);
+
ret = __sys_sendmsg_sock(sock, &kmsg->msg, flags);
if ((issue_flags & IO_URING_F_NONBLOCK) && ret == -EAGAIN)
return io_setup_async_msg(req, kmsg);
@@ -4416,7 +4420,7 @@ static int io_sendmsg(struct io_kiocb *req, unsigned int issue_flags)
if (kmsg->free_iov)
kfree(kmsg->free_iov);
req->flags &= ~REQ_F_NEED_CLEANUP;
- if (ret < 0)
+ if (ret < min_ret)
req_set_fail_links(req);
__io_req_complete(req, issue_flags, ret, 0);
return 0;
@@ -4429,6 +4433,7 @@ static int io_send(struct io_kiocb *req, unsigned int issue_flags)
struct iovec iov;
struct socket *sock;
unsigned flags;
+ int min_ret = 0;
int ret;
sock = sock_from_file(req->file);
@@ -4450,6 +4455,9 @@ static int io_send(struct io_kiocb *req, unsigned int issue_flags)
else if (issue_flags & IO_URING_F_NONBLOCK)
flags |= MSG_DONTWAIT;
+ if (flags & MSG_WAITALL)
+ min_ret = iov_iter_count(&msg.msg_iter);
+
msg.msg_flags = flags;
ret = sock_sendmsg(sock, &msg);
if ((issue_flags & IO_URING_F_NONBLOCK) && ret == -EAGAIN)
@@ -4457,7 +4465,7 @@ static int io_send(struct io_kiocb *req, unsigned int issue_flags)
if (ret == -ERESTARTSYS)
ret = -EINTR;
- if (ret < 0)
+ if (ret < min_ret)
req_set_fail_links(req);
__io_req_complete(req, issue_flags, ret, 0);
return 0;
@@ -4609,6 +4617,7 @@ static int io_recvmsg(struct io_kiocb *req, unsigned int issue_flags)
struct socket *sock;
struct io_buffer *kbuf;
unsigned flags;
+ int min_ret = 0;
int ret, cflags = 0;
bool force_nonblock = issue_flags & IO_URING_F_NONBLOCK;
@@ -4640,6 +4649,9 @@ static int io_recvmsg(struct io_kiocb *req, unsigned int issue_flags)
else if (force_nonblock)
flags |= MSG_DONTWAIT;
+ if (flags & MSG_WAITALL)
+ min_ret = iov_iter_count(&kmsg->msg.msg_iter);
+
ret = __sys_recvmsg_sock(sock, &kmsg->msg, req->sr_msg.umsg,
kmsg->uaddr, flags);
if (force_nonblock && ret == -EAGAIN)
@@ -4653,7 +4665,7 @@ static int io_recvmsg(struct io_kiocb *req, unsigned int issue_flags)
if (kmsg->free_iov)
kfree(kmsg->free_iov);
req->flags &= ~REQ_F_NEED_CLEANUP;
- if (ret < 0)
+ if (ret < min_ret || ((flags & MSG_WAITALL) && (kmsg->msg.msg_flags & (MSG_TRUNC | MSG_CTRUNC))))
req_set_fail_links(req);
__io_req_complete(req, issue_flags, ret, cflags);
return 0;
@@ -4668,6 +4680,7 @@ static int io_recv(struct io_kiocb *req, unsigned int issue_flags)
struct socket *sock;
struct iovec iov;
unsigned flags;
+ int min_ret = 0;
int ret, cflags = 0;
bool force_nonblock = issue_flags & IO_URING_F_NONBLOCK;
@@ -4699,6 +4712,9 @@ static int io_recv(struct io_kiocb *req, unsigned int issue_flags)
else if (force_nonblock)
flags |= MSG_DONTWAIT;
+ if (flags & MSG_WAITALL)
+ min_ret = iov_iter_count(&msg.msg_iter);
+
ret = sock_recvmsg(sock, &msg, flags);
if (force_nonblock && ret == -EAGAIN)
return -EAGAIN;
@@ -4707,7 +4723,7 @@ static int io_recv(struct io_kiocb *req, unsigned int issue_flags)
out_free:
if (req->flags & REQ_F_BUFFER_SELECTED)
cflags = io_put_recv_kbuf(req);
- if (ret < 0)
+ if (ret < min_ret || ((flags & MSG_WAITALL) && (msg.msg_flags & (MSG_TRUNC | MSG_CTRUNC))))
req_set_fail_links(req);
__io_req_complete(req, issue_flags, ret, cflags);
return 0;
--
2.25.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v2 1/1] io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with MSG_WAITALL
2021-03-20 19:33 ` [PATCH v2 1/1] io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with MSG_WAITALL Stefan Metzmacher
@ 2021-03-20 22:57 ` Jens Axboe
2021-03-21 10:20 ` Stefan Metzmacher
0 siblings, 1 reply; 5+ messages in thread
From: Jens Axboe @ 2021-03-20 22:57 UTC (permalink / raw
To: Stefan Metzmacher, io-uring; +Cc: netdev
On 3/20/21 1:33 PM, Stefan Metzmacher wrote:
> Without that it's not safe to use them in a linked combination with
> others.
>
> Now combinations like IORING_OP_SENDMSG followed by IORING_OP_SPLICE
> should be possible.
>
> We already handle short reads and writes for the following opcodes:
>
> - IORING_OP_READV
> - IORING_OP_READ_FIXED
> - IORING_OP_READ
> - IORING_OP_WRITEV
> - IORING_OP_WRITE_FIXED
> - IORING_OP_WRITE
> - IORING_OP_SPLICE
> - IORING_OP_TEE
>
> Now we have it for these as well:
>
> - IORING_OP_SENDMSG
> - IORING_OP_SEND
> - IORING_OP_RECVMSG
> - IORING_OP_RECV
>
> For IORING_OP_RECVMSG we also check for the MSG_TRUNC and MSG_CTRUNC
> flags in order to call req_set_fail_links().
>
> There might be applications arround depending on the behavior
> that even short send[msg]()/recv[msg]() retuns continue an
> IOSQE_IO_LINK chain.
>
> It's very unlikely that such applications pass in MSG_WAITALL,
> which is only defined in 'man 2 recvmsg', but not in 'man 2 sendmsg'.
>
> It's expected that the low level sock_sendmsg() call just ignores
> MSG_WAITALL, as MSG_ZEROCOPY is also ignored without explicitly set
> SO_ZEROCOPY.
>
> We also expect the caller to know about the implicit truncation to
> MAX_RW_COUNT, which we don't detect.
Thanks, I do think this is much better and I feel comfortable getting
htis applied for 5.12 (and stable).
--
Jens Axboe
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 1/1] io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with MSG_WAITALL
@ 2021-03-21 1:07 kernel test robot
0 siblings, 0 replies; 5+ messages in thread
From: kernel test robot @ 2021-03-21 1:07 UTC (permalink / raw
To: kbuild
[-- Attachment #1: Type: text/plain, Size: 6117 bytes --]
CC: kbuild-all(a)lists.01.org
In-Reply-To: <12efc18b6bef3955500080a238197e90ca6a402c.1616268538.git.metze@samba.org>
References: <12efc18b6bef3955500080a238197e90ca6a402c.1616268538.git.metze(a)samba.org>
TO: Stefan Metzmacher <metze@samba.org>
TO: io-uring(a)vger.kernel.org
CC: Stefan Metzmacher <metze@samba.org>
CC: netdev(a)vger.kernel.org
Hi Stefan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.12-rc3 next-20210319]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Stefan-Metzmacher/io_uring-call-req_set_fail_links-on-short-send-msg-recv-msg-with-MSG_WAITALL/20210321-043429
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 812da4d39463a060738008a46cfc9f775e4bfcf6
:::::: branch date: 5 hours ago
:::::: commit date: 5 hours ago
config: x86_64-randconfig-m001-20210321 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
smatch warnings:
fs/io_uring.c:4726 io_recv() error: uninitialized symbol 'flags'.
vim +/flags +4726 fs/io_uring.c
0fa03c624d8fc9 Jens Axboe 2019-04-19 4673
889fca73287b0a Pavel Begunkov 2021-02-10 4674 static int io_recv(struct io_kiocb *req, unsigned int issue_flags)
fddafacee287b3 Jens Axboe 2020-01-04 4675 {
6b754c8b912a16 Pavel Begunkov 2020-07-16 4676 struct io_buffer *kbuf;
fddafacee287b3 Jens Axboe 2020-01-04 4677 struct io_sr_msg *sr = &req->sr_msg;
fddafacee287b3 Jens Axboe 2020-01-04 4678 struct msghdr msg;
7a7cacba8b4560 Pavel Begunkov 2020-07-16 4679 void __user *buf = sr->buf;
7a7cacba8b4560 Pavel Begunkov 2020-07-16 4680 struct socket *sock;
fddafacee287b3 Jens Axboe 2020-01-04 4681 struct iovec iov;
fddafacee287b3 Jens Axboe 2020-01-04 4682 unsigned flags;
715a5ad1957c48 Stefan Metzmacher 2021-03-20 4683 int min_ret = 0;
7a7cacba8b4560 Pavel Begunkov 2020-07-16 4684 int ret, cflags = 0;
45d189c6062922 Pavel Begunkov 2021-02-10 4685 bool force_nonblock = issue_flags & IO_URING_F_NONBLOCK;
7a7cacba8b4560 Pavel Begunkov 2020-07-16 4686
dba4a9256bb4d7 Florent Revest 2020-12-04 4687 sock = sock_from_file(req->file);
7a7cacba8b4560 Pavel Begunkov 2020-07-16 4688 if (unlikely(!sock))
dba4a9256bb4d7 Florent Revest 2020-12-04 4689 return -ENOTSOCK;
fddafacee287b3 Jens Axboe 2020-01-04 4690
bc02ef3325e3ef Pavel Begunkov 2020-07-16 4691 if (req->flags & REQ_F_BUFFER_SELECT) {
7fbb1b541f4286 Pavel Begunkov 2020-07-16 4692 kbuf = io_recv_buffer_select(req, !force_nonblock);
bcda7baaa3f15c Jens Axboe 2020-02-23 4693 if (IS_ERR(kbuf))
bcda7baaa3f15c Jens Axboe 2020-02-23 4694 return PTR_ERR(kbuf);
bcda7baaa3f15c Jens Axboe 2020-02-23 4695 buf = u64_to_user_ptr(kbuf->addr);
bcda7baaa3f15c Jens Axboe 2020-02-23 4696 }
fddafacee287b3 Jens Axboe 2020-01-04 4697
7a7cacba8b4560 Pavel Begunkov 2020-07-16 4698 ret = import_single_range(READ, buf, sr->len, &iov, &msg.msg_iter);
14c32eee928662 Pavel Begunkov 2020-07-16 4699 if (unlikely(ret))
14c32eee928662 Pavel Begunkov 2020-07-16 4700 goto out_free;
fddafacee287b3 Jens Axboe 2020-01-04 4701
fddafacee287b3 Jens Axboe 2020-01-04 4702 msg.msg_name = NULL;
fddafacee287b3 Jens Axboe 2020-01-04 4703 msg.msg_control = NULL;
fddafacee287b3 Jens Axboe 2020-01-04 4704 msg.msg_controllen = 0;
fddafacee287b3 Jens Axboe 2020-01-04 4705 msg.msg_namelen = 0;
fddafacee287b3 Jens Axboe 2020-01-04 4706 msg.msg_iocb = NULL;
fddafacee287b3 Jens Axboe 2020-01-04 4707 msg.msg_flags = 0;
fddafacee287b3 Jens Axboe 2020-01-04 4708
76cd979f4f38a2 Stefan Metzmacher 2021-03-16 4709 flags = req->sr_msg.msg_flags | MSG_NOSIGNAL;
fddafacee287b3 Jens Axboe 2020-01-04 4710 if (flags & MSG_DONTWAIT)
fddafacee287b3 Jens Axboe 2020-01-04 4711 req->flags |= REQ_F_NOWAIT;
fddafacee287b3 Jens Axboe 2020-01-04 4712 else if (force_nonblock)
fddafacee287b3 Jens Axboe 2020-01-04 4713 flags |= MSG_DONTWAIT;
fddafacee287b3 Jens Axboe 2020-01-04 4714
715a5ad1957c48 Stefan Metzmacher 2021-03-20 4715 if (flags & MSG_WAITALL)
715a5ad1957c48 Stefan Metzmacher 2021-03-20 4716 min_ret = iov_iter_count(&msg.msg_iter);
715a5ad1957c48 Stefan Metzmacher 2021-03-20 4717
0b7b21e42ba2d6 Jens Axboe 2020-01-31 4718 ret = sock_recvmsg(sock, &msg, flags);
fddafacee287b3 Jens Axboe 2020-01-04 4719 if (force_nonblock && ret == -EAGAIN)
fddafacee287b3 Jens Axboe 2020-01-04 4720 return -EAGAIN;
fddafacee287b3 Jens Axboe 2020-01-04 4721 if (ret == -ERESTARTSYS)
fddafacee287b3 Jens Axboe 2020-01-04 4722 ret = -EINTR;
14c32eee928662 Pavel Begunkov 2020-07-16 4723 out_free:
7fbb1b541f4286 Pavel Begunkov 2020-07-16 4724 if (req->flags & REQ_F_BUFFER_SELECTED)
7fbb1b541f4286 Pavel Begunkov 2020-07-16 4725 cflags = io_put_recv_kbuf(req);
715a5ad1957c48 Stefan Metzmacher 2021-03-20 @4726 if (ret < min_ret || ((flags & MSG_WAITALL) && (msg.msg_flags & (MSG_TRUNC | MSG_CTRUNC))))
fddafacee287b3 Jens Axboe 2020-01-04 4727 req_set_fail_links(req);
889fca73287b0a Pavel Begunkov 2021-02-10 4728 __io_req_complete(req, issue_flags, ret, cflags);
fddafacee287b3 Jens Axboe 2020-01-04 4729 return 0;
fddafacee287b3 Jens Axboe 2020-01-04 4730 }
fddafacee287b3 Jens Axboe 2020-01-04 4731
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 32702 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 1/1] io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with MSG_WAITALL
2021-03-20 22:57 ` Jens Axboe
@ 2021-03-21 10:20 ` Stefan Metzmacher
2021-03-21 13:10 ` Jens Axboe
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Metzmacher @ 2021-03-21 10:20 UTC (permalink / raw
To: Jens Axboe, io-uring; +Cc: netdev
Am 20.03.21 um 23:57 schrieb Jens Axboe:
> On 3/20/21 1:33 PM, Stefan Metzmacher wrote:
>> Without that it's not safe to use them in a linked combination with
>> others.
>>
>> Now combinations like IORING_OP_SENDMSG followed by IORING_OP_SPLICE
>> should be possible.
>>
>> We already handle short reads and writes for the following opcodes:
>>
>> - IORING_OP_READV
>> - IORING_OP_READ_FIXED
>> - IORING_OP_READ
>> - IORING_OP_WRITEV
>> - IORING_OP_WRITE_FIXED
>> - IORING_OP_WRITE
>> - IORING_OP_SPLICE
>> - IORING_OP_TEE
>>
>> Now we have it for these as well:
>>
>> - IORING_OP_SENDMSG
>> - IORING_OP_SEND
>> - IORING_OP_RECVMSG
>> - IORING_OP_RECV
>>
>> For IORING_OP_RECVMSG we also check for the MSG_TRUNC and MSG_CTRUNC
>> flags in order to call req_set_fail_links().
>>
>> There might be applications arround depending on the behavior
>> that even short send[msg]()/recv[msg]() retuns continue an
>> IOSQE_IO_LINK chain.
>>
>> It's very unlikely that such applications pass in MSG_WAITALL,
>> which is only defined in 'man 2 recvmsg', but not in 'man 2 sendmsg'.
>>
>> It's expected that the low level sock_sendmsg() call just ignores
>> MSG_WAITALL, as MSG_ZEROCOPY is also ignored without explicitly set
>> SO_ZEROCOPY.
>>
>> We also expect the caller to know about the implicit truncation to
>> MAX_RW_COUNT, which we don't detect.
>
> Thanks, I do think this is much better and I feel comfortable getting
> htis applied for 5.12 (and stable).
>
Great thanks!
Related to that I have a questing regarding the IOSQE_IO_LINK behavior.
(Assuming I have a dedicated ring for the send-path of each socket.)
Is it possible to just set IOSQE_IO_LINK on every sqe in order to create
an endless chain of requests so that userspace can pass as much sqes as possible
which all need to be submitted in the exact correct order. And if any request
is short, then all remaining get ECANCELED, without the risk of running any later
request out of order.
Are such link chains possible also over multiple io_uring_submit() calls?
Is there still a race between, having an iothread removing the request from
from the list and fill in a cqe with ECANCELED, that userspace is not awaire
of yet, which then starts a new independed link chain with a request that
ought to be submitted after all the canceled once.
Or do I have to submit a link chain with just a single __io_uring_flush_sq()
and then strictly need to wait until I got a cqe for the last request in
the chain?
Thanks!
metze
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 1/1] io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with MSG_WAITALL
2021-03-21 10:20 ` Stefan Metzmacher
@ 2021-03-21 13:10 ` Jens Axboe
0 siblings, 0 replies; 5+ messages in thread
From: Jens Axboe @ 2021-03-21 13:10 UTC (permalink / raw
To: Stefan Metzmacher, io-uring; +Cc: netdev
On 3/21/21 4:20 AM, Stefan Metzmacher wrote:
>
> Am 20.03.21 um 23:57 schrieb Jens Axboe:
>> On 3/20/21 1:33 PM, Stefan Metzmacher wrote:
>>> Without that it's not safe to use them in a linked combination with
>>> others.
>>>
>>> Now combinations like IORING_OP_SENDMSG followed by IORING_OP_SPLICE
>>> should be possible.
>>>
>>> We already handle short reads and writes for the following opcodes:
>>>
>>> - IORING_OP_READV
>>> - IORING_OP_READ_FIXED
>>> - IORING_OP_READ
>>> - IORING_OP_WRITEV
>>> - IORING_OP_WRITE_FIXED
>>> - IORING_OP_WRITE
>>> - IORING_OP_SPLICE
>>> - IORING_OP_TEE
>>>
>>> Now we have it for these as well:
>>>
>>> - IORING_OP_SENDMSG
>>> - IORING_OP_SEND
>>> - IORING_OP_RECVMSG
>>> - IORING_OP_RECV
>>>
>>> For IORING_OP_RECVMSG we also check for the MSG_TRUNC and MSG_CTRUNC
>>> flags in order to call req_set_fail_links().
>>>
>>> There might be applications arround depending on the behavior
>>> that even short send[msg]()/recv[msg]() retuns continue an
>>> IOSQE_IO_LINK chain.
>>>
>>> It's very unlikely that such applications pass in MSG_WAITALL,
>>> which is only defined in 'man 2 recvmsg', but not in 'man 2 sendmsg'.
>>>
>>> It's expected that the low level sock_sendmsg() call just ignores
>>> MSG_WAITALL, as MSG_ZEROCOPY is also ignored without explicitly set
>>> SO_ZEROCOPY.
>>>
>>> We also expect the caller to know about the implicit truncation to
>>> MAX_RW_COUNT, which we don't detect.
>>
>> Thanks, I do think this is much better and I feel comfortable getting
>> htis applied for 5.12 (and stable).
>>
>
> Great thanks!
>
> Related to that I have a questing regarding the IOSQE_IO_LINK behavior.
> (Assuming I have a dedicated ring for the send-path of each socket.)
>
> Is it possible to just set IOSQE_IO_LINK on every sqe in order to create
> an endless chain of requests so that userspace can pass as much sqes as possible
> which all need to be submitted in the exact correct order. And if any request
> is short, then all remaining get ECANCELED, without the risk of running any later
> request out of order.
>
> Are such link chains possible also over multiple io_uring_submit() calls?
> Is there still a race between, having an iothread removing the request from
> from the list and fill in a cqe with ECANCELED, that userspace is not awaire
> of yet, which then starts a new independed link chain with a request that
> ought to be submitted after all the canceled once.
>
> Or do I have to submit a link chain with just a single __io_uring_flush_sq()
> and then strictly need to wait until I got a cqe for the last request in
> the chain?
A chain can only exist within a single submit attempt, so it will not work
if you need to break it up over multiple io_uring_enter() calls.
--
Jens Axboe
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-03-21 13:11 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-03-21 1:07 [PATCH v2 1/1] io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with MSG_WAITALL kernel test robot
-- strict thread matches above, loose matches on Subject: below --
2021-03-16 15:33 [PATCH 1/2] io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() calls Stefan Metzmacher
2021-03-20 19:33 ` [PATCH v2 1/1] io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with MSG_WAITALL Stefan Metzmacher
2021-03-20 22:57 ` Jens Axboe
2021-03-21 10:20 ` Stefan Metzmacher
2021-03-21 13:10 ` Jens Axboe
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.