[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH V2 1/2] tests/libqtest: Fix possible deadlock in
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH V2 1/2] tests/libqtest: Fix possible deadlock in qtest initialization |
Date: |
Tue, 11 Mar 2014 19:50:36 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, Mar 11, 2014 at 03:04:22PM +0200, Marcel Apfelbaum wrote:
> 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.
I think you are right. I checked that the qtest protocol has no
long-running operations. It doesn't seem realistic that any qtest
command would take 5 seconds or longer.
So let's leave in the timeout.
Stefan
[Qemu-devel] [PATCH V2 2/2] tests: Tweak the Makefile to produce per-test output., Marcel Apfelbaum, 2014/03/11