From: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: kwolf@redhat.com, stefanha@redhat.com, qemu-devel@nongnu.org,
armbru@redhat.com, aliguori@amazon.com, afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH V2 1/2] tests/libqtest: Fix possible deadlock in qtest initialization
Date: Tue, 11 Mar 2014 15:04:22 +0200 [thread overview]
Message-ID: <1394543062.3981.41.camel@localhost.localdomain> (raw)
In-Reply-To: <1394542311.3981.37.camel@localhost.localdomain>
On Tue, 2014-03-11 at 14:51 +0200, Marcel Apfelbaum wrote:
> On Tue, 2014-03-11 at 13:40 +0100, Stefan Hajnoczi wrote:
> > On Tue, Mar 11, 2014 at 12:09:09PM +0200, Marcel Apfelbaum wrote:
> > > @@ -78,12 +79,16 @@ static int socket_accept(int sock)
> > > struct sockaddr_un addr;
> > > socklen_t addrlen;
> > > int ret;
> > > + struct timeval timeout = { .tv_sec = SOCKET_TIMEOUT,
> > > + .tv_usec = 0 };
> > > +
> > > + setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, (void *)&timeout,
> > > + sizeof(timeout));
> > >
> > > addrlen = sizeof(addr);
> > > do {
> > > ret = accept(sock, (struct sockaddr *)&addr, &addrlen);
> > > } while (ret == -1 && errno == EINTR);
> > > - g_assert_no_errno(ret);
> > > close(sock);
> >
> > Did you mean to leave SO_RCVTIMEO set after this function completes?
> Yes, I don't think it hurts. A 5 sec timeout should be like infinite,
> Qemu running on the same machine. If you think
... otherwise, I can remove the timeout, but I think it is OK.
>
> >
> > > @@ -91,7 +96,7 @@ static int socket_accept(int sock)
> > >
> > > static void kill_qemu(QTestState *s)
> > > {
> > > - if (s->qemu_pid != -1) {
> > > + if (s && s->qemu_pid != -1) {
> > > kill(s->qemu_pid, SIGTERM);
> > > waitpid(s->qemu_pid, NULL, 0);
> > > }
> >
> > This is a bug in libqtest.c, please don't silence the crash.
> I didn't see it like hiding a crash, I thought that if there
> is any problem during init it is because the Qemu failed to start,
> meaning that you don't have a process to kill (Qemu exited already).
> Al of the above happens -> you don't have a global state.
>
> Anyway, if you have a better way to deal with it, I have nothing against it :)
>
> Thanks,
> Marcel
>
> >
> > kill_qemu() gets called from the SIGABRT signal handler but I forgot
> > that global_qtest isn't initialized yet while qtest_init() executes.
> >
> > In other words, the cleanup is broken if we fail inside qtest_init().
> > Can you drop this hunk and I'll send a patch to fix the underlying
> > issue?
I dropped it, please take care of it as it gets a segmentation fault
if we abort in qtest_init.
Thanks,
Marcel
> >
> > > @@ -153,6 +158,8 @@ QTestState *qtest_init(const char *extra_args)
> > > g_free(socket_path);
> > > g_free(qmp_socket_path);
> > >
> > > + g_assert(s->fd >= 0 && s->qmp_fd >= 0);
> > > +
> >
> > We probably shouldn't socket_accept() s->qmp_fd if s->fd already failed.
> > Otherwise we'll wait another 5 seconds for the timeout to explire:
> Yes, I already had this chunk, I have no idea why I dropped it, I'll
> return it, thanks.
>
> Thanks,
> Marcel
> >
> > s->fd = socket_accept(sock);
> > if (s->fd >= 0) {
> > s->qmp_fd = socket_accept(qmpsock);
> > }
>
>
>
>
next prev parent reply other threads:[~2014-03-11 13:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-11 10:09 [Qemu-devel] [PATCH V2 0/2] tests: Fix possible deadlock in qtest initialization Marcel Apfelbaum
2014-03-11 10:09 ` [Qemu-devel] [PATCH V2 1/2] tests/libqtest: " Marcel Apfelbaum
2014-03-11 12:40 ` Stefan Hajnoczi
2014-03-11 12:51 ` Marcel Apfelbaum
2014-03-11 13:04 ` Marcel Apfelbaum [this message]
2014-03-11 18:50 ` Stefan Hajnoczi
2014-03-11 10:09 ` [Qemu-devel] [PATCH V2 2/2] tests: Tweak the Makefile to produce per-test output Marcel Apfelbaum
2014-03-11 12:07 ` Eric Blake
2014-03-11 12:27 ` Marcel Apfelbaum
2014-03-11 12:45 ` Stefan Hajnoczi
2014-03-11 12:52 ` Marcel Apfelbaum
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=1394543062.3981.41.camel@localhost.localdomain \
--to=marcel.apfelbaum@gmail.com \
--cc=afaerber@suse.de \
--cc=aliguori@amazon.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=marcel.a@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).