Bug 855737
Summary: | libusbredirhost should not queue unlimited amounts of data, causing oom | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Marko Myllynen <myllynen> |
Component: | usbredir | Assignee: | Hans de Goede <hdegoede> |
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 6.3 | CC: | cfergeau, dblechte, dyasny, hdegoede, mkrcmari |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | usbredir-0.5.1-1.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-02-21 08:50:43 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Marko Myllynen
2012-09-10 07:09:36 UTC
This happens with both RHEL 6 / Windows 7 guests using Spice in Native mode. Thanks for the report: 1) First of all, what you're trying to do is never going to work. You simply cannot redirect a USB-2 webcam which generates up-to 240 Mbit / sec of video data over a slow network (e.g., VPN over 3G). usbredir works at the USB level, so it does not know about video frames, so it cannot implement frame drop or something similar. To redirect a webcam you simply need at least as much bandwidth on the network as the webcam is using in USB bandwidth 2) With that said, the resulting behavior of course is not acceptable, what happens is that libusbredirhost is running the webcam at full-speed (the only speed available) and feeding video data to libusbredirparser as fast as it comes in. usbredirparser then puts this in its write queue, and since it is coming in faster then the write queue is getting emptied at the other end, the write queue grows boundlessly. Fixing this should not be that hard, what it needs is a new libusbredirparser function to check how large the write queue is, and for libusbredirhost to drop isochronous data packets when the queue is too large (we cannot drop other packet types as the USB standard guarantees reliable delivery for all other packet types). This is fixed by the new usbredir-0.5.1 upstream release. This is fixed by usbredir-0.5.1-1.el6, moving to modified. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0346.html |