Re: [Qemu-devel] [PATCH V2 1/2] tests/libqtest: Fix possible deadlock in qtest initialization

[Stefan Hajnoczi]

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