From: Jens Freimann <jfreimann@redhat.com>
To: Marc-Andr?? Lureau <marcandre.lureau@gmail.com>
Cc: QEMU <qemu-devel@nongnu.org>,
Victor Kaplansky <victork@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>,
Maxime Coquelin <maxime.coquelin@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 3/5] libvhost-user: quit when no more data received
Date: Thu, 21 Sep 2017 15:31:37 +0200 [thread overview]
Message-ID: <20170921133137.dbs6o6mwe6tm3joh@localhost.localdomain> (raw)
In-Reply-To: <CAJ+F1CJVZxt3pWW1GEuy+0KNab4wxY4wc8A-raMPzTF5Qq_G4Q@mail.gmail.com>
On Wed, Sep 20, 2017 at 04:14:33PM +0000, Marc-Andr?? Lureau wrote:
>On Wed, Sep 20, 2017 at 5:09 PM, Jens Freimann <jfreimann@redhat.com> wrote:
>> On Tue, Sep 19, 2017 at 04:46:24PM +0000, Marc-Andr?? Lureau wrote:
>>>
>>> Hi
>>>
>>> On Tue, Aug 8, 2017 at 10:52 PM Jens Freimann <jfreimann@redhat.com>
>>> wrote:
>>>>
>>>>
>>>> From: Jens Freimann <jfreiman@redhat.com>
>>>>
>>>> End processing of messages when VHOST_USER_NONE
>>>> is received.
>>>>
>>>> Without this we run into a vubr_panic() call and get
>>>> "PANIC: Unhandled request: 0"
>>>>
>>>> Signed-off-by: Jens Freimann <jfreiman@redhat.com>
>>>> ---
>>>> contrib/libvhost-user/libvhost-user.c | 4 +++-
>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/contrib/libvhost-user/libvhost-user.c
>>>> b/contrib/libvhost-user/libvhost-user.c
>>>> index 9efb9dac0e..35fa0c5e56 100644
>>>> --- a/contrib/libvhost-user/libvhost-user.c
>>>> +++ b/contrib/libvhost-user/libvhost-user.c
>>>> @@ -161,7 +161,7 @@ vu_message_read(VuDev *dev, int conn_fd, VhostUserMsg
>>>> *vmsg)
>>>> rc = recvmsg(conn_fd, &msg, 0);
>>>> } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
>>>>
>>>> - if (rc <= 0) {
>>>> + if (rc < 0) {
>>>> vu_panic(dev, "Error while recvmsg: %s", strerror(errno));
>>>> return false;
>>>> }
>>>> @@ -806,6 +806,8 @@ vu_process_message(VuDev *dev, VhostUserMsg *vmsg)
>>>> return vu_get_queue_num_exec(dev, vmsg);
>>>> case VHOST_USER_SET_VRING_ENABLE:
>>>> return vu_set_vring_enable_exec(dev, vmsg);
>>>> + case VHOST_USER_NONE:
>>>> + break;
>>>
>>>
>>>
>>> I am afraid this isn't working. vu_message_read() returns
>>> true/success, vu_process_message() returns false/no-reply, so
>>> vu_dispatch() will return success, and the caller has no clear way to
>>> know that the socket got disconnected. For me the vu_panic() was quite
>>> more appropriate here.
>>>
>>> What problem did this patch exactly solve?
>>
>>
>> The problem was that a VhostUserMsg of size 0 is considered an
>> error. But recvmsg() can return 0. When I ran my pxe
>
>When did recvmsg() return 0? It should only be called after a poll
>IN/ERR, in case of data it should always return != 0, and if
>disconnected, it returns 0.
My usecase is that my testcase starts a pxeboot data transfer that
goes through vhost-user-bridge. When the transfer is done the socket
is disconnected and recvmsg() returns 0. I want vhost-user-bridge to
end gracefully, without spitting out an error message. Is that
reasonable?
>
>> testcase using vhost-user-bridge I ran into vu_panic() because of this.
>> This worked because VHOST_USER_NONE is defined as 0. Instead of
>> doing this we could just allow a vmsg size of zero and not tread it
>> as an error?
>
>We want to treat disconnect as a panic condition imho, that the
>library user is free to implement in different way (abort() clean
>exit, reconnect etc).
Ok, that wasn't obvious to me. Thanks for clarifying!
So I was "fixing" the wrong part. On a disconnect vubr_panic() in
vhost-user-bridge.c is called and is supposed to do the right thing.
Currently it will print an error message "PANIC: Unhandled request:
0" in my use case. I could ignore that or check for exactly this
string and suppress the error message. Both seems a bit ugly to me...
>
>Please explain your use case and how you ran into recvmsg() = 0 and
>what you expect to happen at this point.
Hope this helps! Looks like we can revert this patch. I'll send a
patch to do this.
regards,
Jens
next prev parent reply other threads:[~2017-09-21 13:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-08 20:38 [Qemu-devel] [PATCH v2 0/5] tests/pxe-test: add testcase using vhost-user-bridge Jens Freimann
2017-08-08 20:38 ` [Qemu-devel] [PATCH v2 1/5] tests/vhost-user-bridge: disable debug output by default Jens Freimann
2017-08-08 20:38 ` [Qemu-devel] [PATCH v2 2/5] net: fix -netdev socket, fd= for UDP sockets Jens Freimann
2017-11-03 18:46 ` Peter Maydell
2017-11-06 10:49 ` Jens Freimann
2017-08-08 20:38 ` [Qemu-devel] [PATCH v2 3/5] libvhost-user: quit when no more data received Jens Freimann
2017-09-19 16:46 ` Marc-André Lureau
2017-09-20 15:09 ` Jens Freimann
2017-09-20 16:14 ` Marc-André Lureau
2017-09-21 13:31 ` Jens Freimann [this message]
2017-09-21 16:05 ` Jens Freimann
2017-08-08 20:38 ` [Qemu-devel] [PATCH v2 4/5] libqtest: always set up signal handler for SIGABRT Jens Freimann
2017-08-08 20:39 ` [Qemu-devel] [PATCH v2 5/5] tests/pxe-test: add testcase using vhost-user-bridge Jens Freimann
2017-08-08 21:05 ` [Qemu-devel] [PATCH for-2.10? v2 0/5] " Eric Blake
2017-08-08 22:18 ` Michael S. Tsirkin
2017-08-08 23:59 ` [Qemu-devel] [PATCH " no-reply
2017-08-09 1:17 ` Michael S. Tsirkin
2017-08-09 8:21 ` Jens Freimann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170921133137.dbs6o6mwe6tm3joh@localhost.localdomain \
--to=jfreimann@redhat.com \
--cc=jasowang@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=maxime.coquelin@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=victork@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).