Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Using a virtio serial port from an application, filling it until the write command returns -EAGAIN and then executing a select command for the write command, caused the select command to not return any values when using the virtio serial port in a non-blocking mode. When used in blocking mode, the write command waited until the host indicated it had used up the buffers. This was due to the fact that the poll operation waited for the port->waitqueue pointer; however, nothing woke the waitqueue when there was room again in the queue. With this update, the queue is woken via host notifications so that buffers consumed by the host can be reclaimed, the queue freed, and the application write operations may proceed again.
When using a virtio serial port from an application and putting it in non blocking mode, then fulling it till write returns -EAGAIN and then doing a select
for write, the select will never returns.
The reason for this is that poll waits for port->waitqueue, but nothing
wakes the waitqueue when there is room again in the queue, quoting from virtio_console.c: init_vqs():
io_callbacks[j] = in_intr;
io_callbacks[j + 1] = NULL;
The fix is to simply define a callback for the j + 1 case, and make this wait the waitqueue all the other needed bits are already present.
Some notes my original description of this problem comes from reading the code, not from hitting this in practice. Amit Shah has run some tests and cannot re-create the problem which one would expect up on reading the code.
We've discussed this and decided to keep this bug open for further investigation later to see if the waitqueue in question is somehow actually woken when room becomes available in the out_vq, or if things currently happen to work because of some side-effect somewhere else.
Comment 4RHEL Program Management
2011-01-07 04:34:22 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
This request was erroneously denied for the current release of Red Hat
Enterprise Linux. The error has been fixed and this request has been
re-proposed for the current release.
Comment 7RHEL Program Management
2011-01-28 11:50:39 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update release.
Comment 8RHEL Program Management
2011-01-28 14:10:50 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update release.
Testing notes:
With qemu-kvm with the fix for bug 588916, start a guest with:
-chardev socket,path=/tmp/foo,server,nowait,id=c0 -device virtio-serial -device virtserialport,chardev=c0
Then redirect the port to a file:
nc -U /tmp/foo > /tmp/guest-file
In the guest, transfer a big file (anything > 1G) to the virtio port:
cat /tmp/bigfile > /dev/vport0p1
In some cases, the guest command will never finish and the size of the host file will not increase beyond a particular number.
After the kernel with this bug solved is used, the 'cat' command in the guest will finish and the size of the file in the host will match the size of the file in the guest.
Comment 11Aristeu Rozanski
2011-02-03 19:06:36 UTC
Verified on qemu-kvm-0.12.1.2-2.144.el6.
guest kernel : kernel-2.6.32-113.el6
steps:
1.start VM with virtio-serial-port w/o -M parameter.
2.open the socket file on the host and not read it
eg:#cat open-socket
#!/usr/bin/python
import os
import sys
import socket
import time
#fd = os.open(sys.argv[1], os.O_RDONLY)
s = socket.socket(socket.AF_UNIX)
s.connect(sys.argv[1])
while 1:
# do nothing
time.sleep(1)
#python open-socket /tmp/vport0
3.transfer a file whose size > 2G via virtio-serial
eg :#cat /tt > /dev/vport0p1
Actual Results:
qemu-kvm process does not freeze.
Based on above ,this issue has been fixed.
Change status to VERIFIED.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Using a virtio serial port from an application, filling it until the write command returns -EAGAIN and then executing a select command for the write command, caused the select command to not return any values when using the virtio serial port in a non-blocking mode. When used in blocking mode, the write command waited until the host indicated it had used up the buffers. This was due to the fact that the poll operation waited for the port->waitqueue pointer; however, nothing woke the waitqueue when there was room again in the queue. With this update, the queue is woken via host notifications so that buffers consumed by the host can be reclaimed, the queue freed, and the application write operations may proceed again.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
http://rhn.redhat.com/errata/RHSA-2011-0542.html
When using a virtio serial port from an application and putting it in non blocking mode, then fulling it till write returns -EAGAIN and then doing a select for write, the select will never returns. The reason for this is that poll waits for port->waitqueue, but nothing wakes the waitqueue when there is room again in the queue, quoting from virtio_console.c: init_vqs(): io_callbacks[j] = in_intr; io_callbacks[j + 1] = NULL; The fix is to simply define a callback for the j + 1 case, and make this wait the waitqueue all the other needed bits are already present.