Re: [Qemu-devel] vhost-user devices work with chardev from different threads

[Marc-André Lureau]

Hi

On Mon, Oct 22, 2018 at 5:24 PM Yury Kotov <address@hidden> wrote:
>
> Hi,
>
> I examined vhost-user devices and found some chardev using strangeness.
>
> Is it ok, that vhost-user's set_status do sync chardev io ops from KVM thread?
> It seems that chardev doesn't support working with different threads.
>
> For example, I think such race is possible (two simultaneous events):
> 1) Vhost-user server was killed (main thread will handle G_IO_HUP),
> 2) Virtio-pci bus handles guest driver's set_status command.
>    Some io op from vhost-user backend will fail because of 1).
>
> So, it is possible to enter tcp_chr_disconnect twice from the main thread and
> from KVM thread.
>
> Backtrace examples:
>
> KVM thread (handle set_status of guest):
> tcp_chr_disconnect
> tcp_chr_write (cc->chr_write)
> qemu_chr_write_buffer
> qemu_chr_write
> qemu_chr_fe_write_all
> vhost_user_write
> vhost_user_set_mem_table (hdev->vhost_ops->vhost_set_mem_table)
> vhost_dev_start
> vhost_user_blk_start (or another vhost-user device)
> vhost_user_blk_set_status (vdc->set_status)
>
> Main thread (handle vhost server disconnect):
> tcp_chr_disconnect
> tcp_chr_hup
> g_main_context_dispatch
> glib_pollfds_poll
> os_host_main_loop_wait
> main_loop_wait
> main_loop
> main
>
> Is it really a problem or do I misunderstand?

I think you are correct, it's a problem. Are you working on a
solution? (either using the chardev lock, or perhaps relying on main
thread HUP handler only, or a combination of both approaches)

thanks

-- 
Marc-André Lureau