Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. May 03, 2017
    • Hailiang Zhang's avatar
      char: Fix removing wrong GSource that be found by fd_in_tag · b19456dd
      Hailiang Zhang authored 
      
We use fd_in_tag to find a GSource, fd_in_tag is return value of
g_source_attach(GSource *source, GMainContext *context), the return
value is unique only in the same context, so we may get the same
values with different 'context' parameters.

It is no problem to find the right fd_in_tag by using
 g_main_context_find_source_by_id(GMainContext *context, guint source_id)
while there is only one default main context.

But colo-compare tries to create/use its own context, and if we pass wrong
'context' parameter with right fd_in_tag, we will find a wrong GSource to handle.
We tried to fix the related codes in commit b43decb0,
but it didn't fix the bug completely, because we still have some codes didn't pass
*right* context parameter for remove_fd_in_watch().

Let's fix it by record the GSource directly instead of fd_in_tag.

Signed-off-by: default avatarzhanghailiang <zhang.zhanghailiang@huawei.com>
Reviewed-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1492564532-91680-1-git-send-email-zhang.zhanghailiang@huawei.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      b19456dd
  3. Apr 03, 2017
  5. Mar 06, 2017
  7. Feb 20, 2017
  9. Feb 16, 2017
    • Ed Swierk's avatar
      char: drop data written to a disconnected pty · 1c64fdbc
      Ed Swierk authored 
      
When a serial port writes data to a pty that's disconnected, drop the
data and return the length dropped. This avoids triggering pointless
retries in callers like the 16550A serial_xmit(), and causes
qemu_chr_fe_write() to write all data to the log file, rather than
logging only while a pty client like virsh console happens to be
connected.

Signed-off-by: default avatarEd Swierk <eswierk@skyportsystems.com>
Message-Id: <1485870329-79428-1-git-send-email-eswierk@skyportsystems.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      1c64fdbc
    • Anton Nefedov's avatar
      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
  11. Jan 31, 2017