All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Cc: Klim Kireev <klim.kireev@virtuozzo.com>,
	marcandre.lureau@redhat.com,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: [Qemu-devel] "make check -j4" hangs (was: Re: chardev/char-socket: add POLLHUP handler)
Date: Thu, 8 Feb 2018 20:13:26 +0100	[thread overview]
Message-ID: <fd22674c-059e-8d37-338c-5d2d4d96eb20@redhat.com> (raw)
In-Reply-To: <bb1b8270-e924-3d41-a172-38ba79db9bf7@redhat.com>

On 30.01.2018 20:49, Paolo Bonzini wrote:
> On 25/01/2018 08:51, Klim Kireev wrote:
>> The following behavior was observed for QEMU configured by libvirt
>> to use guest agent as usual for the guests without virtio-serial
>> driver (Windows or the guest remaining in BIOS stage).
>>
>> In QEMU on first connect to listen character device socket
>> the listen socket is removed from poll just after the accept().
>> virtio_serial_guest_ready() returns 0 and the descriptor
>> of the connected Unix socket is removed from poll and it will
>> not be present in poll() until the guest will initialize the driver
>> and change the state of the serial to "guest connected".
>>
>> In libvirt connect() to guest agent is performed on restart and
>> is run under VM state lock. Connect() is blocking and can
>> wait forever.
>> In this case libvirt can not perform ANY operation on that VM.
>>
>> The bug can be easily reproduced this way:
>>
>> Terminal 1:
>> qemu-system-x86_64 -m 512 -device pci-serial,chardev=serial1 -chardev socket,id=serial1,path=/tmp/console.sock,server,nowait
>> (virtio-serial and isa-serial also fit)
>>
>> Terminal 2:
>> minicom -D unix\#/tmp/console.sock
>> (type something and press enter)
>> C-a x (to exit)
>>
>> Do 3 times:
>> minicom -D unix\#/tmp/console.sock
>> C-a x
>>
>> It needs 4 connections, because the first one is accepted by QEMU, then two are queued by
>> the kernel, and the 4th blocks.
>>
>> The problem is that QEMU doesn't add a read watcher after succesful read
>> until the guest device wants to acquire recieved data, so
>> I propose to install a separate pullhup watcher regardless of
>> whether the device waits for data or not.
>>
>> Signed-off-by: Klim Kireev <klim.kireev@virtuozzo.com>
>> ---
>> Changelog:
>> v2: Remove timer as a redundant feature
>>
>> v3: Remove read call and return G_SOURCE_REMOVE
>>
>> v4: Move to GSource API
>>
>> v5: Fix git typos 
>>
>>  chardev/char-socket.c | 22 ++++++++++++++++++++++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/chardev/char-socket.c b/chardev/char-socket.c
>> index 77cdf487eb..a340af6cd3 100644
>> --- a/chardev/char-socket.c
>> +++ b/chardev/char-socket.c
>> @@ -42,6 +42,7 @@ typedef struct {
>>      QIOChannel *ioc; /* Client I/O channel */
>>      QIOChannelSocket *sioc; /* Client master channel */
>>      QIONetListener *listener;
>> +    GSource *hup_source;
>>      QCryptoTLSCreds *tls_creds;
>>      int connected;
>>      int max_size;
>> @@ -352,6 +353,12 @@ static void tcp_chr_free_connection(Chardev *chr)
>>          s->read_msgfds_num = 0;
>>      }
>>  
>> +    if (s->hup_source != NULL) {
>> +        g_source_destroy(s->hup_source);
>> +        g_source_unref(s->hup_source);
>> +        s->hup_source = NULL;
>> +    }
>> +
>>      tcp_set_msgfds(chr, NULL, 0);
>>      remove_fd_in_watch(chr);
>>      object_unref(OBJECT(s->sioc));
>> @@ -455,6 +462,15 @@ static gboolean tcp_chr_read(QIOChannel *chan, GIOCondition cond, void *opaque)
>>      return TRUE;
>>  }
>>  
>> +static gboolean tcp_chr_hup(QIOChannel *channel,
>> +                               GIOCondition cond,
>> +                               void *opaque)
>> +{
>> +    Chardev *chr = CHARDEV(opaque);
>> +    tcp_chr_disconnect(chr);
>> +    return G_SOURCE_REMOVE;
>> +}
>> +
>>  static int tcp_chr_sync_read(Chardev *chr, const uint8_t *buf, int len)
>>  {
>>      SocketChardev *s = SOCKET_CHARDEV(chr);
>> @@ -528,6 +544,12 @@ static void tcp_chr_connect(void *opaque)
>>                                             tcp_chr_read,
>>                                             chr, chr->gcontext);
>>      }
>> +
>> +    s->hup_source = qio_channel_create_watch(s->ioc, G_IO_HUP);
>> +    g_source_set_callback(s->hup_source, (GSourceFunc)tcp_chr_hup,
>> +                          chr, NULL);
>> +    g_source_attach(s->hup_source, chr->gcontext);
>> +
>>      qemu_chr_be_event(chr, CHR_EVENT_OPENED);
>>  }
>>  
>>
> 
> Queued, thanks.

 Hi!

I'm currently facing some issues with "make check -j4" (i.e. running the
tests in parallel). Git bisect blames this commit - though I'm not sure
whether this is really the right one ... Starting with this commit, I
saw hangs in test-filter-redirector, but git master rather seems to hang
with vhost-user-test instead.
Stefan also had issues with "make check -j4" today, so it's apparently
not only me ... can somebody else reproduce the problem with the git
master branch?

 Thomas

  reply	other threads:[~2018-02-08 19:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-25 13:51 [Qemu-devel] [PATCH v5] chardev/char-socket: add POLLHUP handler Klim Kireev
2018-01-30 19:49 ` Paolo Bonzini
2018-02-08 19:13   ` Thomas Huth [this message]
2018-02-08 21:12     ` [Qemu-devel] "make check -j4" hangs (was: Re: chardev/char-socket: add POLLHUP handler) Peter Maydell
2018-02-08 21:54       ` Alistair Francis
2018-02-09 11:55         ` [Qemu-devel] "make check -j4" hangs Paolo Bonzini
2018-02-12 14:42           ` klim
2018-02-12 19:30             ` Thomas Huth
2018-02-12 22:14               ` Paolo Bonzini
2018-02-13 11:21               ` Peter Maydell
2018-02-09 12:47     ` Klim Kireev
2018-02-09 16:03       ` Thomas Huth

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=fd22674c-059e-8d37-338c-5d2d4d96eb20@redhat.com \
    --to=thuth@redhat.com \
    --cc=klim.kireev@virtuozzo.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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.