| Message ID | 20221213213850.1481858-2-peterx@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | migration: Fix disorder of channel creations | expand |
On Tue, Dec 13, 2022 at 04:38:46PM -0500, Peter Xu wrote: > From: "manish.mishra" <manish.mishra@nutanix.com> > > MSG_PEEK reads from the peek of channel, The data is treated as > unread and the next read shall still return this data. This > support is currently added only for socket class. Extra parameter > 'flags' is added to io_readv calls to pass extra read flags like > MSG_PEEK. > > Reviewed-by: Daniel P. Berrang?? <berrange@redhat.co > Suggested-by: Daniel P. Berrang?? <berrange@redhat.com The last letter of my name has been mangled - whatever tools used to pull in manish's patches seem to not be UTF-8 clean. Also the email addr isn't terminated, but that was pre-existing in manish's previous posting. With regards, Daniel
On Wed, Dec 14, 2022 at 09:14:09AM +0000, Daniel P. Berrangé wrote: > On Tue, Dec 13, 2022 at 04:38:46PM -0500, Peter Xu wrote: > > From: "manish.mishra" <manish.mishra@nutanix.com> > > > > MSG_PEEK reads from the peek of channel, The data is treated as > > unread and the next read shall still return this data. This > > support is currently added only for socket class. Extra parameter > > 'flags' is added to io_readv calls to pass extra read flags like > > MSG_PEEK. > > > > Reviewed-by: Daniel P. Berrang?? <berrange@redhat.co > > Suggested-by: Daniel P. Berrang?? <berrange@redhat.com > > The last letter of my name has been mangled - whatever tools used > to pull in manish's patches seem to not be UTF-8 clean. > > Also the email addr isn't terminated, but that was pre-existing > in manish's previous posting. I'll fix at least the latter in my next post, sorry. For the 1st one - I am still looking at what went wrong. Here from the web interfaces it all looks good (besides the wrong ending..), e.g. on lore or patchew: https://lore.kernel.org/all/20221213213850.1481858-2-peterx@redhat.com/ https://patchew.org/QEMU/20221213213850.1481858-1-peterx@redhat.com/20221213213850.1481858-2-peterx@redhat.com/ It also looks good with e.g. Gmail webclient. Then I digged into the email headers and I found that comparing to Manish's original message, the patches I posted has one more line of "Content-type": Content-Type: text/plain; charset="utf-8" Content-type: text/plain https://patchew.org/QEMU/20221213213850.1481858-2-peterx@redhat.com/mbox While Manish's patch only has one line: Content-Type: text/plain; charset="utf-8" https://patchew.org/QEMU/20221123172735.25181-2-manish.mishra@nutanix.com/mbox I found that it also happens in my local mail archive, so with my local mail client it doesn't show correctly either (mutt here). After I manually removed that extra Content-type line in the archive it went right even locally on mutt. So it seems the 2nd "Content-type: text/plain" overwrote the first one and it may not correctly apply utf-8 in the email client depending on what the email client uses as default. Said that, I'm pretty sure my muttrc has: set charset = "UTF-8" set send_charset = "UTF-8" So neither do I know why that mutt config didn't apply to these patches, nor do I (yet..) have an idea where that extra line comes from.. :-(
On Wed, Dec 14, 2022 at 04:30:48PM -0500, Peter Xu wrote: > On Wed, Dec 14, 2022 at 09:14:09AM +0000, Daniel P. Berrangé wrote: > > On Tue, Dec 13, 2022 at 04:38:46PM -0500, Peter Xu wrote: > > > From: "manish.mishra" <manish.mishra@nutanix.com> > > > > > > MSG_PEEK reads from the peek of channel, The data is treated as > > > unread and the next read shall still return this data. This > > > support is currently added only for socket class. Extra parameter > > > 'flags' is added to io_readv calls to pass extra read flags like > > > MSG_PEEK. > > > > > > Reviewed-by: Daniel P. Berrang?? <berrange@redhat.co > > > Suggested-by: Daniel P. Berrang?? <berrange@redhat.com > > > > The last letter of my name has been mangled - whatever tools used > > to pull in manish's patches seem to not be UTF-8 clean. > > > > Also the email addr isn't terminated, but that was pre-existing > > in manish's previous posting. > > I'll fix at least the latter in my next post, sorry. > > For the 1st one - I am still looking at what went wrong. > > Here from the web interfaces it all looks good (besides the wrong > ending..), e.g. on lore or patchew: > > https://lore.kernel.org/all/20221213213850.1481858-2-peterx@redhat.com/ > https://patchew.org/QEMU/20221213213850.1481858-1-peterx@redhat.com/20221213213850.1481858-2-peterx@redhat.com/ > > It also looks good with e.g. Gmail webclient. > > Then I digged into the email headers and I found that comparing to Manish's > original message, the patches I posted has one more line of "Content-type": > > Content-Type: text/plain; charset="utf-8" > Content-type: text/plain > https://patchew.org/QEMU/20221213213850.1481858-2-peterx@redhat.com/mbox > > While Manish's patch only has one line: > > Content-Type: text/plain; charset="utf-8" > https://patchew.org/QEMU/20221123172735.25181-2-manish.mishra@nutanix.com/mbox Don't trust what is shown by patchew, as that's been through many hops. The copy I receieved came directly to me via CC, so didn't hit mailman, nor patchew, and that *only* has "Content-type: text/plain". So the extra Content-type line with utf8 must have been added either by mailman or patchew. So it probably looks like a config problem in the tool you use to send the patches originally. With regards, Daniel
On Thu, Dec 15, 2022 at 09:40:41AM +0000, Daniel P. Berrangé wrote: > On Wed, Dec 14, 2022 at 04:30:48PM -0500, Peter Xu wrote: > > On Wed, Dec 14, 2022 at 09:14:09AM +0000, Daniel P. Berrangé wrote: > > > On Tue, Dec 13, 2022 at 04:38:46PM -0500, Peter Xu wrote: > > > > From: "manish.mishra" <manish.mishra@nutanix.com> > > > > > > > > MSG_PEEK reads from the peek of channel, The data is treated as > > > > unread and the next read shall still return this data. This > > > > support is currently added only for socket class. Extra parameter > > > > 'flags' is added to io_readv calls to pass extra read flags like > > > > MSG_PEEK. > > > > > > > > Reviewed-by: Daniel P. Berrang?? <berrange@redhat.co > > > > Suggested-by: Daniel P. Berrang?? <berrange@redhat.com > > > > > > The last letter of my name has been mangled - whatever tools used > > > to pull in manish's patches seem to not be UTF-8 clean. > > > > > > Also the email addr isn't terminated, but that was pre-existing > > > in manish's previous posting. > > > > I'll fix at least the latter in my next post, sorry. > > > > For the 1st one - I am still looking at what went wrong. > > > > Here from the web interfaces it all looks good (besides the wrong > > ending..), e.g. on lore or patchew: > > > > https://lore.kernel.org/all/20221213213850.1481858-2-peterx@redhat.com/ > > https://patchew.org/QEMU/20221213213850.1481858-1-peterx@redhat.com/20221213213850.1481858-2-peterx@redhat.com/ > > > > It also looks good with e.g. Gmail webclient. > > > > Then I digged into the email headers and I found that comparing to Manish's > > original message, the patches I posted has one more line of "Content-type": > > > > Content-Type: text/plain; charset="utf-8" > > Content-type: text/plain > > https://patchew.org/QEMU/20221213213850.1481858-2-peterx@redhat.com/mbox > > > > While Manish's patch only has one line: > > > > Content-Type: text/plain; charset="utf-8" > > https://patchew.org/QEMU/20221123172735.25181-2-manish.mishra@nutanix.com/mbox > > Don't trust what is shown by patchew, as that's been through many > hops. > > The copy I receieved came directly to me via CC, so didn't hit mailman, > nor patchew, and that *only* has "Content-type: text/plain". So the > extra Content-type line with utf8 must have been added either by > mailman or patchew. > > So it probably looks like a config problem in the tool you use to send > the patches originally. Ouch... for misterious reasons I had one line in .gitconfig: 177 [format] 178 headers = "Content-type: text/plain" And that'll also affect git-publish too... I have it dropped now. Thanks,
On 15/12/22 11:05 pm, Peter Xu wrote: > On Thu, Dec 15, 2022 at 09:40:41AM +0000, Daniel P. Berrangé wrote: >> On Wed, Dec 14, 2022 at 04:30:48PM -0500, Peter Xu wrote: >>> On Wed, Dec 14, 2022 at 09:14:09AM +0000, Daniel P. Berrangé wrote: >>>> On Tue, Dec 13, 2022 at 04:38:46PM -0500, Peter Xu wrote: >>>>> From: "manish.mishra" <manish.mishra@nutanix.com> >>>>> >>>>> MSG_PEEK reads from the peek of channel, The data is treated as >>>>> unread and the next read shall still return this data. This >>>>> support is currently added only for socket class. Extra parameter >>>>> 'flags' is added to io_readv calls to pass extra read flags like >>>>> MSG_PEEK. >>>>> >>>>> Reviewed-by: Daniel P. Berrang?? <berrange@redhat.co >>>>> Suggested-by: Daniel P. Berrang?? <berrange@redhat.com >>>> The last letter of my name has been mangled - whatever tools used >>>> to pull in manish's patches seem to not be UTF-8 clean. >>>> >>>> Also the email addr isn't terminated, but that was pre-existing >>>> in manish's previous posting. Yes sorry, noticed it now, should i send another patch to update it. Also in our internal testing we noticed multifd_init was skipped for 1 case, so if this patch series is not yet submitted should i send another version of it early morning monday? Thanks Manish Mishra >>> I'll fix at least the latter in my next post, sorry. >>> >>> For the 1st one - I am still looking at what went wrong. >>> >>> Here from the web interfaces it all looks good (besides the wrong >>> ending..), e.g. on lore or patchew: >>> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_all_20221213213850.1481858-2D2-2Dpeterx-40redhat.com_&d=DwIDaQ&c=s883GpUCOChKOHiocYtGcg&r=c4KON2DiMd-szjwjggQcuUvTsPWblztAL0gVzaHnNmc&m=UYXwYmi1YA2mdAgHNDIkmgh-Xbem8hmqgCedCRNaj-32GKMVK8X30wH3nnXE9VF9&s=_9G0TGvGLvwCdB7vumPEboQqcrX5RoaxZ_4aZTnMDzY&e= >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchew.org_QEMU_20221213213850.1481858-2D1-2Dpeterx-40redhat.com_20221213213850.1481858-2D2-2Dpeterx-40redhat.com_&d=DwIDaQ&c=s883GpUCOChKOHiocYtGcg&r=c4KON2DiMd-szjwjggQcuUvTsPWblztAL0gVzaHnNmc&m=UYXwYmi1YA2mdAgHNDIkmgh-Xbem8hmqgCedCRNaj-32GKMVK8X30wH3nnXE9VF9&s=Nv0ek8VsMHEDFdQ--vwCOrwxT_u1KqbV9014SQzI1kQ&e= >>> >>> It also looks good with e.g. Gmail webclient. >>> >>> Then I digged into the email headers and I found that comparing to Manish's >>> original message, the patches I posted has one more line of "Content-type": >>> >>> Content-Type: text/plain; charset="utf-8" >>> Content-type: text/plain >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchew.org_QEMU_20221213213850.1481858-2D2-2Dpeterx-40redhat.com_mbox&d=DwIDaQ&c=s883GpUCOChKOHiocYtGcg&r=c4KON2DiMd-szjwjggQcuUvTsPWblztAL0gVzaHnNmc&m=UYXwYmi1YA2mdAgHNDIkmgh-Xbem8hmqgCedCRNaj-32GKMVK8X30wH3nnXE9VF9&s=wD5Y-ZvvyUOVKpYHJkM7M8znJ3BjjpkbRIE1NVlMloI&e= >>> >>> While Manish's patch only has one line: >>> >>> Content-Type: text/plain; charset="utf-8" >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchew.org_QEMU_20221123172735.25181-2D2-2Dmanish.mishra-40nutanix.com_mbox&d=DwIDaQ&c=s883GpUCOChKOHiocYtGcg&r=c4KON2DiMd-szjwjggQcuUvTsPWblztAL0gVzaHnNmc&m=UYXwYmi1YA2mdAgHNDIkmgh-Xbem8hmqgCedCRNaj-32GKMVK8X30wH3nnXE9VF9&s=eQ3eyB3GvzUzyHdjTlWTt14dw4x0PL2xSbmXWPfN104&e= >> Don't trust what is shown by patchew, as that's been through many >> hops. >> >> The copy I receieved came directly to me via CC, so didn't hit mailman, >> nor patchew, and that *only* has "Content-type: text/plain". So the >> extra Content-type line with utf8 must have been added either by >> mailman or patchew. >> >> So it probably looks like a config problem in the tool you use to send >> the patches originally. > Ouch... for misterious reasons I had one line in .gitconfig: > > 177 [format] > 178 headers = "Content-type: text/plain" > > And that'll also affect git-publish too... I have it dropped now. > > Thanks, >
On Fri, Dec 16, 2022 at 04:10:22PM +0530, manish.mishra wrote: > Yes sorry, noticed it now, should i send another patch to update it. Also > in our internal testing we noticed multifd_init was skipped for 1 case, > so if this patch series is not yet submitted should i send another > version of it early morning monday? I think yes. Thanks,
diff --git a/chardev/char-socket.c b/chardev/char-socket.c index 879564aa8a..5afce9a464 100644 --- a/chardev/char-socket.c +++ b/chardev/char-socket.c @@ -283,11 +283,11 @@ static ssize_t tcp_chr_recv(Chardev *chr, char *buf, size_t len) if (qio_channel_has_feature(s->ioc, QIO_CHANNEL_FEATURE_FD_PASS)) { ret = qio_channel_readv_full(s->ioc, &iov, 1, &msgfds, &msgfds_num, - NULL); + 0, NULL); } else { ret = qio_channel_readv_full(s->ioc, &iov, 1, NULL, NULL, - NULL); + 0, NULL); } if (msgfds_num) { diff --git a/include/io/channel.h b/include/io/channel.h index c680ee7480..716235d496 100644 --- a/include/io/channel.h +++ b/include/io/channel.h @@ -34,6 +34,8 @@ OBJECT_DECLARE_TYPE(QIOChannel, QIOChannelClass, #define QIO_CHANNEL_WRITE_FLAG_ZERO_COPY 0x1 +#define QIO_CHANNEL_READ_FLAG_MSG_PEEK 0x1 + typedef enum QIOChannelFeature QIOChannelFeature; enum QIOChannelFeature { @@ -41,6 +43,7 @@ enum QIOChannelFeature { QIO_CHANNEL_FEATURE_SHUTDOWN, QIO_CHANNEL_FEATURE_LISTEN, QIO_CHANNEL_FEATURE_WRITE_ZERO_COPY, + QIO_CHANNEL_FEATURE_READ_MSG_PEEK, }; @@ -114,6 +117,7 @@ struct QIOChannelClass { size_t niov, int **fds, size_t *nfds, + int flags, Error **errp); int (*io_close)(QIOChannel *ioc, Error **errp); @@ -188,6 +192,7 @@ void qio_channel_set_name(QIOChannel *ioc, * @niov: the length of the @iov array * @fds: pointer to an array that will received file handles * @nfds: pointer filled with number of elements in @fds on return + * @flags: read flags (QIO_CHANNEL_READ_FLAG_*) * @errp: pointer to a NULL-initialized error object * * Read data from the IO channel, storing it in the @@ -224,6 +229,7 @@ ssize_t qio_channel_readv_full(QIOChannel *ioc, size_t niov, int **fds, size_t *nfds, + int flags, Error **errp); diff --git a/io/channel-buffer.c b/io/channel-buffer.c index bf52011be2..8096180f85 100644 --- a/io/channel-buffer.c +++ b/io/channel-buffer.c @@ -54,6 +54,7 @@ static ssize_t qio_channel_buffer_readv(QIOChannel *ioc, size_t niov, int **fds, size_t *nfds, + int flags, Error **errp) { QIOChannelBuffer *bioc = QIO_CHANNEL_BUFFER(ioc); diff --git a/io/channel-command.c b/io/channel-command.c index 74516252ba..e7edd091af 100644 --- a/io/channel-command.c +++ b/io/channel-command.c @@ -203,6 +203,7 @@ static ssize_t qio_channel_command_readv(QIOChannel *ioc, size_t niov, int **fds, size_t *nfds, + int flags, Error **errp) { QIOChannelCommand *cioc = QIO_CHANNEL_COMMAND(ioc); diff --git a/io/channel-file.c b/io/channel-file.c index b67687c2aa..d76663e6ae 100644 --- a/io/channel-file.c +++ b/io/channel-file.c @@ -86,6 +86,7 @@ static ssize_t qio_channel_file_readv(QIOChannel *ioc, size_t niov, int **fds, size_t *nfds, + int flags, Error **errp) { QIOChannelFile *fioc = QIO_CHANNEL_FILE(ioc); diff --git a/io/channel-null.c b/io/channel-null.c index 75e3781507..4fafdb770d 100644 --- a/io/channel-null.c +++ b/io/channel-null.c @@ -60,6 +60,7 @@ qio_channel_null_readv(QIOChannel *ioc, size_t niov, int **fds G_GNUC_UNUSED, size_t *nfds G_GNUC_UNUSED, + int flags, Error **errp) { QIOChannelNull *nioc = QIO_CHANNEL_NULL(ioc); diff --git a/io/channel-socket.c b/io/channel-socket.c index b76dca9cc1..dfb8cb6c40 100644 --- a/io/channel-socket.c +++ b/io/channel-socket.c @@ -173,6 +173,8 @@ int qio_channel_socket_connect_sync(QIOChannelSocket *ioc, } #endif + qio_channel_set_feature(QIO_CHANNEL(ioc), QIO_CHANNEL_FEATURE_READ_MSG_PEEK); + return 0; } @@ -406,6 +408,8 @@ qio_channel_socket_accept(QIOChannelSocket *ioc, } #endif /* WIN32 */ + qio_channel_set_feature(QIO_CHANNEL(cioc), QIO_CHANNEL_FEATURE_READ_MSG_PEEK); + trace_qio_channel_socket_accept_complete(ioc, cioc, cioc->fd); return cioc; @@ -496,6 +500,7 @@ static ssize_t qio_channel_socket_readv(QIOChannel *ioc, size_t niov, int **fds, size_t *nfds, + int flags, Error **errp) { QIOChannelSocket *sioc = QIO_CHANNEL_SOCKET(ioc); @@ -517,6 +522,10 @@ static ssize_t qio_channel_socket_readv(QIOChannel *ioc, } + if (flags & QIO_CHANNEL_READ_FLAG_MSG_PEEK) { + sflags |= MSG_PEEK; + } + retry: ret = recvmsg(sioc->fd, &msg, sflags); if (ret < 0) { @@ -624,11 +633,17 @@ static ssize_t qio_channel_socket_readv(QIOChannel *ioc, size_t niov, int **fds, size_t *nfds, + int flags, Error **errp) { QIOChannelSocket *sioc = QIO_CHANNEL_SOCKET(ioc); ssize_t done = 0; ssize_t i; + int sflags = 0; + + if (flags & QIO_CHANNEL_READ_FLAG_MSG_PEEK) { + sflags |= MSG_PEEK; + } for (i = 0; i < niov; i++) { ssize_t ret; @@ -636,7 +651,7 @@ static ssize_t qio_channel_socket_readv(QIOChannel *ioc, ret = recv(sioc->fd, iov[i].iov_base, iov[i].iov_len, - 0); + sflags); if (ret < 0) { if (errno == EAGAIN) { if (done) { diff --git a/io/channel-tls.c b/io/channel-tls.c index 4ce890a538..c730cb8ec5 100644 --- a/io/channel-tls.c +++ b/io/channel-tls.c @@ -260,6 +260,7 @@ static ssize_t qio_channel_tls_readv(QIOChannel *ioc, size_t niov, int **fds, size_t *nfds, + int flags, Error **errp) { QIOChannelTLS *tioc = QIO_CHANNEL_TLS(ioc); diff --git a/io/channel-websock.c b/io/channel-websock.c index fb4932ade7..a12acc27cf 100644 --- a/io/channel-websock.c +++ b/io/channel-websock.c @@ -1081,6 +1081,7 @@ static ssize_t qio_channel_websock_readv(QIOChannel *ioc, size_t niov, int **fds, size_t *nfds, + int flags, Error **errp) { QIOChannelWebsock *wioc = QIO_CHANNEL_WEBSOCK(ioc); diff --git a/io/channel.c b/io/channel.c index 0640941ac5..a8c7f11649 100644 --- a/io/channel.c +++ b/io/channel.c @@ -52,6 +52,7 @@ ssize_t qio_channel_readv_full(QIOChannel *ioc, size_t niov, int **fds, size_t *nfds, + int flags, Error **errp) { QIOChannelClass *klass = QIO_CHANNEL_GET_CLASS(ioc); @@ -63,7 +64,14 @@ ssize_t qio_channel_readv_full(QIOChannel *ioc, return -1; } - return klass->io_readv(ioc, iov, niov, fds, nfds, errp); + if ((flags & QIO_CHANNEL_READ_FLAG_MSG_PEEK) && + !qio_channel_has_feature(ioc, QIO_CHANNEL_FEATURE_READ_MSG_PEEK)) { + error_setg_errno(errp, EINVAL, + "Channel does not support peek read"); + return -1; + } + + return klass->io_readv(ioc, iov, niov, fds, nfds, flags, errp); } @@ -146,7 +154,7 @@ int qio_channel_readv_full_all_eof(QIOChannel *ioc, while ((nlocal_iov > 0) || local_fds) { ssize_t len; len = qio_channel_readv_full(ioc, local_iov, nlocal_iov, local_fds, - local_nfds, errp); + local_nfds, 0, errp); if (len == QIO_CHANNEL_ERR_BLOCK) { if (qemu_in_coroutine()) { qio_channel_yield(ioc, G_IO_IN); @@ -284,7 +292,7 @@ ssize_t qio_channel_readv(QIOChannel *ioc, size_t niov, Error **errp) { - return qio_channel_readv_full(ioc, iov, niov, NULL, NULL, errp); + return qio_channel_readv_full(ioc, iov, niov, NULL, NULL, 0, errp); } @@ -303,7 +311,7 @@ ssize_t qio_channel_read(QIOChannel *ioc, Error **errp) { struct iovec iov = { .iov_base = buf, .iov_len = buflen }; - return qio_channel_readv_full(ioc, &iov, 1, NULL, NULL, errp); + return qio_channel_readv_full(ioc, &iov, 1, NULL, NULL, 0, errp); } diff --git a/migration/channel-block.c b/migration/channel-block.c index f4ab53acdb..b7374363c3 100644 --- a/migration/channel-block.c +++ b/migration/channel-block.c @@ -53,6 +53,7 @@ qio_channel_block_readv(QIOChannel *ioc, size_t niov, int **fds, size_t *nfds, + int flags, Error **errp) { QIOChannelBlock *bioc = QIO_CHANNEL_BLOCK(ioc); diff --git a/migration/rdma.c b/migration/rdma.c index 94a55dd95b..d8b4632094 100644 --- a/migration/rdma.c +++ b/migration/rdma.c @@ -2854,6 +2854,7 @@ static ssize_t qio_channel_rdma_readv(QIOChannel *ioc, size_t niov, int **fds, size_t *nfds, + int flags, Error **errp) { QIOChannelRDMA *rioc = QIO_CHANNEL_RDMA(ioc); diff --git a/scsi/qemu-pr-helper.c b/scsi/qemu-pr-helper.c index 196b78c00d..199227a556 100644 --- a/scsi/qemu-pr-helper.c +++ b/scsi/qemu-pr-helper.c @@ -614,7 +614,7 @@ static int coroutine_fn prh_read(PRHelperClient *client, void *buf, int sz, iov.iov_base = buf; iov.iov_len = sz; n_read = qio_channel_readv_full(QIO_CHANNEL(client->ioc), &iov, 1, - &fds, &nfds, errp); + &fds, &nfds, 0, errp); if (n_read == QIO_CHANNEL_ERR_BLOCK) { qio_channel_yield(QIO_CHANNEL(client->ioc), G_IO_IN); diff --git a/tests/qtest/tpm-emu.c b/tests/qtest/tpm-emu.c index 2994d1cf42..3cf1acaf7d 100644 --- a/tests/qtest/tpm-emu.c +++ b/tests/qtest/tpm-emu.c @@ -106,7 +106,7 @@ void *tpm_emu_ctrl_thread(void *data) int *pfd = NULL; size_t nfd = 0; - qio_channel_readv_full(ioc, &iov, 1, &pfd, &nfd, &error_abort); + qio_channel_readv_full(ioc, &iov, 1, &pfd, &nfd, 0, &error_abort); cmd = be32_to_cpu(cmd); g_assert_cmpint(cmd, ==, CMD_SET_DATAFD); g_assert_cmpint(nfd, ==, 1); diff --git a/tests/unit/test-io-channel-socket.c b/tests/unit/test-io-channel-socket.c index b36a5d972a..b964bb202d 100644 --- a/tests/unit/test-io-channel-socket.c +++ b/tests/unit/test-io-channel-socket.c @@ -460,6 +460,7 @@ static void test_io_channel_unix_fd_pass(void) G_N_ELEMENTS(iorecv), &fdrecv, &nfdrecv, + 0, &error_abort); g_assert(nfdrecv == G_N_ELEMENTS(fdsend)); diff --git a/util/vhost-user-server.c b/util/vhost-user-server.c index 232984ace6..145eb17c08 100644 --- a/util/vhost-user-server.c +++ b/util/vhost-user-server.c @@ -116,7 +116,7 @@ vu_message_read(VuDev *vu_dev, int conn_fd, VhostUserMsg *vmsg) * qio_channel_readv_full may have short reads, keeping calling it * until getting VHOST_USER_HDR_SIZE or 0 bytes in total */ - rc = qio_channel_readv_full(ioc, &iov, 1, &fds, &nfds, &local_err); + rc = qio_channel_readv_full(ioc, &iov, 1, &fds, &nfds, 0, &local_err); if (rc < 0) { if (rc == QIO_CHANNEL_ERR_BLOCK) { assert(local_err == NULL);