Bug 678558 - virtio_console driver never returns from selecting for write when the queue is full [rhel-6.0.z]
Summary: virtio_console driver never returns from selecting for write when the queue i...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Frantisek Hrbata
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On: 643750
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-18 12:28 UTC by RHEL Product and Program Management
Modified: 2013-01-11 03:48 UTC (History)
9 users (show)

Fixed In Version: kernel-2.6.32-71.19.1.el6
Doc Type: Bug Fix
Doc Text:
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.
Clone Of:
Environment:
Last Closed: 2011-04-08 02:59:46 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0421 normal SHIPPED_LIVE Important: kernel security and bug fix update 2011-04-08 02:56:45 UTC

Description RHEL Product and Program Management 2011-02-18 12:28:19 UTC
This bug has been copied from bug #643750 and has been proposed
to be backported to 6.0 z-stream (EUS).

Comment 4 Chao Yang 2011-03-28 02:55:44 UTC
Reproduced on rhel6.0 with kernel 2.6.32-71.el6.x86_64.
Steps:
1. boot a guest with virtio-serial-port
2. open the socket with follwing script
# pythonh open-socket.py /tmp/charsoc
# 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(>2G) via virtio-serial
Actual Result:
guest freezes, cannot respond to keyboard.

CLI:
# /usr/libexec/qemu-kvm -M rhel6.0.0 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name rhel6.0 -uuid `uuidgen` -rtc base=utc -boot c -drive file=/root/RHEL-Server-6.0-64.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:3f:de:3b -device virtio-serial-pci  -chardev socket,path=/tmp/charsoc,id=channel0,server,nowait -device virtserialport,chardev=channel0 -usb -device usb-tablet,id=input1 -vnc :0 -monitor stdio
------------------------------------------------------------------------------
Verified on host kernel kernel-2.6.32-71.23.1.el6.x86_64.rpm with same steps&CLI above, when transferring large file from guest to host via virtio-serial, guest keeps alive and can interrupt cat process.

Comment 5 errata-xmlrpc 2011-04-08 02:59:46 UTC
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-0421.html

Comment 6 Martin Prpič 2011-04-12 12:41:02 UTC
    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.


Note You need to log in before you can comment on or make changes to this bug.