From: "Daniel P. Berrange" <berrange@redhat.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: qemu-devel@nongnu.org, qemu-trivial@nongnu.org,
Gerd Hoffmann <kraxel@redhat.com>,
qemu-stable@nongnu.org
Subject: Re: [Qemu-trivial] [PATCH v2] vnc: do not disconnect on EAGAIN
Date: Fri, 3 Feb 2017 10:07:27 +0000 [thread overview]
Message-ID: <20170203100727.GD10350@redhat.com> (raw)
In-Reply-To: <1486115549-9398-1-git-send-email-mjt@msgid.tls.msk.ru>
On Fri, Feb 03, 2017 at 12:52:29PM +0300, Michael Tokarev wrote:
> When qemu vnc server is trying to send large update to clients,
> there might be a situation when system responds with something
> like EAGAIN, indicating that there's no system memory to send
> that much data (depending on the network speed, client and server
> and what is happening). In this case, something like this happens
> on qemu side (from strace):
>
> sendmsg(16, {msg_name(0)=NULL,
> msg_iov(1)=[{"\244\"..., 729186}],
> msg_controllen=0, msg_flags=0}, 0) = 103950
> sendmsg(16, {msg_name(0)=NULL,
> msg_iov(1)=[{"lz\346"..., 1559618}],
> msg_controllen=0, msg_flags=0}, 0) = -1 EAGAIN
> sendmsg(-1, {msg_name(0)=NULL,
> msg_iov(1)=[{"lz\346"..., 1559618}],
> msg_controllen=0, msg_flags=0}, 0) = -1 EBADF
>
> qemu closes the socket before the retry, and obviously it gets EBADF
> when trying to send to -1.
>
> This is because there WAS a special handling for EAGAIN, but now it doesn't
> work anymore, after commit 04d2529da27db512dcbd5e99d0e26d333f16efcc, because
> now in all error-like cases we initiate vnc disconnect.
>
> This change were introduced in qemu 2.6, and caused numerous grief for many
> people, resulting in their vnc clients reporting sporadic random disconnects
> from vnc server.
>
> Fix that by doing the disconnect only when necessary, i.e. omitting this
> very case of EAGAIN.
>
> Hopefully the existing condition (comparing with QIO_CHANNEL_ERR_BLOCK)
> is sufficient, as the original code (before the above commit) were
> checking for other errno values too.
There's no need to check WSAEWOULDBLOCK anymore - our win32 portability
code already remaps it to EAGAIN.
Checking EINTR is not required because QIOChannelSocket already
restarts the recvmsg/sendmsg when seeing EINTR
> Apparently there's another (semi?)bug exist somewhere here, since the
> code tries to write to fd# -1, it probably should check if the connection
> is open before. But this isn't important.
>
> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
> Fixes: 04d2529da27db512dcbd5e99d0e26d333f16efcc
> Cc: Daniel P. Berrange <berrange@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: qemu-stable@nongnu.org
> ---
> v2: previous patch was tab/space-damaged, fixing this now
>
> ui/vnc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/ui/vnc.c b/ui/vnc.c
> index cdeb79c..f2701e5 100644
> --- a/ui/vnc.c
> +++ b/ui/vnc.c
> @@ -1256,12 +1256,13 @@ ssize_t vnc_client_io_error(VncState *vs, ssize_t ret, Error **errp)
> if (ret <= 0) {
> if (ret == 0) {
> VNC_DEBUG("Closing down client sock: EOF\n");
> + vnc_disconnect_start(vs);
> } else if (ret != QIO_CHANNEL_ERR_BLOCK) {
> VNC_DEBUG("Closing down client sock: ret %zd (%s)\n",
> ret, errp ? error_get_pretty(*errp) : "Unknown");
> + vnc_disconnect_start(vs);
> }
>
> - vnc_disconnect_start(vs);
> if (errp) {
> error_free(*errp);
> *errp = NULL;
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
next prev parent reply other threads:[~2017-02-03 10:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-03 9:52 [Qemu-trivial] [PATCH v2] vnc: do not disconnect on EAGAIN Michael Tokarev
2017-02-03 10:07 ` Daniel P. Berrange [this message]
2017-02-06 14:26 ` Gerd Hoffmann
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=20170203100727.GD10350@redhat.com \
--to=berrange@redhat.com \
--cc=kraxel@redhat.com \
--cc=mjt@tls.msk.ru \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=qemu-trivial@nongnu.org \
/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).