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
