Skip to content
  • Anton Nefedov's avatar
    b0a335e3
    qemu-char: socket backend: disconnect on write error · b0a335e3
    Anton Nefedov authored
    
    
    Socket backend read handler should normally perform a disconnect, however
    the read handler may not get a chance to run if the frontend is not ready
    (qemu_chr_be_can_write() == 0).
    
    This means that in virtio-serial frontend case if
     - the host has disconnected (giving EPIPE on socket write)
     - and the guest has disconnected (-> frontend not ready -> backend
       will not read)
     - and there is still data (frontend->backend) to flush (has to be a really
       tricky timing but nevertheless, we have observed the case in production)
    
    This results in virtio-serial trying to flush this data continiously forming
    a busy loop.
    
    Solution: react on write error in the socket write handler.
    errno is not reliable after qio_channel_writev_full(), so we may not get
    the exact EPIPE, so disconnect on any error but QIO_CHANNEL_ERR_BLOCK which
    io_channel_send_full() converts to errno EAGAIN.
    We must not disconnect right away though, there still may be data to read
    (see 4bf1cb03).
    
    Signed-off-by: default avatarAnton Nefedov <anton.nefedov@virtuozzo.com>
    Signed-off-by: default avatarDenis V. Lunev <den@openvz.org>
    CC: Paolo Bonzini <pbonzini@redhat.com>
    CC: Daniel P. Berrange <berrange@redhat.com>
    CC: Marc-André Lureau <marcandre.lureau@redhat.com>
    Message-Id: <1486045589-8074-1-git-send-email-den@openvz.org>
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    b0a335e3
    qemu-char: socket backend: disconnect on write error
    Anton Nefedov authored
    
    
    Socket backend read handler should normally perform a disconnect, however
    the read handler may not get a chance to run if the frontend is not ready
    (qemu_chr_be_can_write() == 0).
    
    This means that in virtio-serial frontend case if
     - the host has disconnected (giving EPIPE on socket write)
     - and the guest has disconnected (-> frontend not ready -> backend
       will not read)
     - and there is still data (frontend->backend) to flush (has to be a really
       tricky timing but nevertheless, we have observed the case in production)
    
    This results in virtio-serial trying to flush this data continiously forming
    a busy loop.
    
    Solution: react on write error in the socket write handler.
    errno is not reliable after qio_channel_writev_full(), so we may not get
    the exact EPIPE, so disconnect on any error but QIO_CHANNEL_ERR_BLOCK which
    io_channel_send_full() converts to errno EAGAIN.
    We must not disconnect right away though, there still may be data to read
    (see 4bf1cb03).
    
    Signed-off-by: default avatarAnton Nefedov <anton.nefedov@virtuozzo.com>
    Signed-off-by: default avatarDenis V. Lunev <den@openvz.org>
    CC: Paolo Bonzini <pbonzini@redhat.com>
    CC: Daniel P. Berrange <berrange@redhat.com>
    CC: Marc-André Lureau <marcandre.lureau@redhat.com>
    Message-Id: <1486045589-8074-1-git-send-email-den@openvz.org>
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
Loading