From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>
Subject: [PULL 3/5] usbredir: Prevent recursion in usbredir_write
Date: Mon, 13 Jan 2020 14:06:44 +0100 [thread overview]
Message-ID: <20200113130646.30099-4-kraxel@redhat.com> (raw)
In-Reply-To: <20200113130646.30099-1-kraxel@redhat.com>
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
I've got a case where usbredir_write manages to call back into itself
via spice; this patch causes the recursion to fail (0 bytes) the write;
this seems to avoid the deadlock I was previously seeing.
I can't say I fully understand the interaction of usbredir and spice;
but there are a few similar guards in spice and usbredir
to catch other cases especially onces also related to spice_server_char_device_wakeup
This case seems to be triggered by repeated migration+repeated
reconnection of the viewer; but my debugging suggests the migration
finished before this hits.
The backtrace of the hang looks like:
reds_handle_ticket
reds_handle_other_links
reds_channel_do_link
red_channel_connect
spicevmc_connect
usbredir_create_parser
usbredirparser_do_write
usbredir_write
qemu_chr_fe_write
qemu_chr_write
qemu_chr_write_buffer
spice_chr_write
spice_server_char_device_wakeup
red_char_device_wakeup
red_char_device_write_to_device
vmc_write
usbredirparser_do_write
usbredir_write
qemu_chr_fe_write
qemu_chr_write
qemu_chr_write_buffer
qemu_mutex_lock_impl
and we fail as we lang through qemu_chr_write_buffer's lock
twice.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1752320
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20191218113012.13331-1-dgilbert@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
hw/usb/redirect.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
index b5c15586874a..04614778fea2 100644
--- a/hw/usb/redirect.c
+++ b/hw/usb/redirect.c
@@ -114,6 +114,7 @@ struct USBRedirDevice {
CharBackend cs;
bool enable_streams;
bool suppress_remote_wake;
+ bool in_write;
uint8_t debug;
int32_t bootindex;
char *filter_str;
@@ -291,6 +292,13 @@ static int usbredir_write(void *priv, uint8_t *data, int count)
return 0;
}
+ /* Recursion check */
+ if (dev->in_write) {
+ DPRINTF("usbredir_write recursion\n");
+ return 0;
+ }
+ dev->in_write = true;
+
r = qemu_chr_fe_write(&dev->cs, data, count);
if (r < count) {
if (!dev->watch) {
@@ -301,6 +309,7 @@ static int usbredir_write(void *priv, uint8_t *data, int count)
r = 0;
}
}
+ dev->in_write = false;
return r;
}
--
2.18.1
next prev parent reply other threads:[~2020-01-13 13:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-13 13:06 [PULL 0/5] Usb 20200113 patches Gerd Hoffmann
2020-01-13 13:06 ` [PULL 1/5] usb-host: remove 'remote wakeup' flag from configuration descriptor Gerd Hoffmann
2020-01-13 13:06 ` [PULL 2/5] usb-redir: " Gerd Hoffmann
2020-01-13 13:06 ` Gerd Hoffmann [this message]
2020-01-13 13:06 ` [PULL 4/5] xhci: Fix memory leak in xhci_kick_epctx when poweroff GuestOS Gerd Hoffmann
2020-01-13 13:06 ` [PULL 5/5] xhci: recheck slot status Gerd Hoffmann
2020-01-13 14:57 ` [PULL 0/5] Usb 20200113 patches Peter Maydell
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=20200113130646.30099-4-kraxel@redhat.com \
--to=kraxel@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=qemu-devel@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).