RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 855737 - libusbredirhost should not queue unlimited amounts of data, causing oom
Summary: libusbredirhost should not queue unlimited amounts of data, causing oom
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: usbredir
Version: 6.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Hans de Goede
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-10 07:09 UTC by Marko Myllynen
Modified: 2013-02-21 08:50 UTC (History)
5 users (show)

Fixed In Version: usbredir-0.5.1-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 08:50:43 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0346 0 normal SHIPPED_LIVE usbredir bug fix and enhancement update 2013-02-20 20:53:45 UTC

Description Marko Myllynen 2012-09-10 07:09:36 UTC 
Description of problem:
When redirecting a USB stick or a USB webcam with remote-viewer over a campus/site network between a laptop and a RHEV guest everything works as expected and the guest is able to use the redirected USB device without issues.

However, when redirecting a USB webcam over a slow network (e.g., VPN over 3G), remote-viewer rapidly starts to consume huge amounts of memory (several gigabytes if one doesn't close it) causing the local system to start swapping and grind to a halt unless the OOM killer gets it.

remote-viewer should not bring down / make unusable the user's system used to access RHEV guests even when sharing a USB device like webcam over a slow network.

Version-Release number of selected component (if applicable):
virt-viewer-0.5.2-9
usbredir-0.4.3-1
Comment 1 Marko Myllynen 2012-09-10 07:10:19 UTC 
This happens with both RHEL 6 / Windows 7 guests using Spice in Native mode.
Comment 3 Hans de Goede 2012-09-10 07:24:35 UTC 
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).
Comment 4 Hans de Goede 2012-09-19 11:42:36 UTC 
This is fixed by the new usbredir-0.5.1 upstream release.
Comment 5 Hans de Goede 2012-09-21 07:37:15 UTC 
This is fixed by usbredir-0.5.1-1.el6, moving to modified.
Comment 11 errata-xmlrpc 2013-02-21 08:50:43 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.