Skip to content
  • Corentin Chary's avatar
    175b2a6e
    vnc: don't mess up with iohandlers in the vnc thread · 175b2a6e
    Corentin Chary authored
    
    
    The threaded VNC servers messed up with QEMU fd handlers without
    any kind of locking, and that can cause some nasty race conditions.
    
    Using qemu_mutex_lock_iothread() won't work because vnc_dpy_cpy(),
    which will wait for the current job queue to finish, can be called with
    the iothread lock held.
    
    Instead, we now store the data in a temporary buffer, and use a bottom
    half to notify the main thread that new data is available.
    
    vnc_[un]lock_ouput() is still needed to access VncState members like
    abort, csock or jobs_buffer.
    
    Signed-off-by: default avatarCorentin Chary <corentin.chary@gmail.com>
    Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
    175b2a6e
    vnc: don't mess up with iohandlers in the vnc thread
    Corentin Chary authored
    
    
    The threaded VNC servers messed up with QEMU fd handlers without
    any kind of locking, and that can cause some nasty race conditions.
    
    Using qemu_mutex_lock_iothread() won't work because vnc_dpy_cpy(),
    which will wait for the current job queue to finish, can be called with
    the iothread lock held.
    
    Instead, we now store the data in a temporary buffer, and use a bottom
    half to notify the main thread that new data is available.
    
    vnc_[un]lock_ouput() is still needed to access VncState members like
    abort, csock or jobs_buffer.
    
    Signed-off-by: default avatarCorentin Chary <corentin.chary@gmail.com>
    Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
Loading