All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: qemu-devel@nongnu.org, tiwei.bie@intel.com, marcandre.lureau@redhat.com
Cc: stefanha@redhat.com, maxime.coquelin@redhat.com
Subject: [Qemu-devel] vhost-user slave deadlock question
Date: Fri, 1 Mar 2019 19:05:01 +0000	[thread overview]
Message-ID: <20190301190501.GF2851@work-vm> (raw)

Hi,
  I've added a few commands to vhost-user for virtio-fs and
am hitting a deadlock and am trying to figure out what the correct fix
is; suggestions welcome.

My setup is:
  Messages sent over the virtio queues can cause the daemon to need
  to send a request back to qemu along the slave, and qemu must respond with an
  OK/error.  Lets call this command 'setupmapping'.
  In my case I'm reading vhost-user commands in one thread and
  processing the queues in another.

  That normally works OK

My problem:
  If qemu crashes or quits it stops the queues synchronously at a point
when the main loop in qemu wont respond to anything else.  However
if we're unlucky the daemon has already sent a message to qemu and
is waiting for the response; but that response can't arrive because
qemu is shutting down.  So the queue shutdown request never completes.
Then if I kill the daemon forcibly, qemu's handler for the slavefd
wakes up and tries to read data - but it's device has gone and it
crashes.

The trace is:
(Where vuf_* is my device and the structure is pretty much the same
as the others).

vm_state_notify->virtio_set_status->vuf_set_status->vuf_stop->vhost_dev_stop->vhost_virtqueue_stop->vhost_user_get_vring_base->vhost_user_read

So it feels like we need to shut down the slave FD when we shut
down the device;  but it's not clear to me at what level.
In some ways it feels like we need a way to get out if this
hole even if we shut down one queue synchronously.

Is anyone fighting similar cases?

Dave



--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

                 reply	other threads:[~2019-03-01 19:05 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190301190501.GF2851@work-vm \
    --to=dgilbert@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=tiwei.bie@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.