On Wed, Apr 25, 2018 at 07:29:05AM +0000, wangxin (U) wrote: > > > -----Original Message----- > > From: Peter Xu [mailto:pet...@redhat.com] > > Sent: Wednesday, April 25, 2018 11:32 AM > > To: Daniel P. Berrangé <berra...@redhat.com> > > Cc: Dr. David Alan Gilbert <dgilb...@redhat.com>; wangxin (U) > > <wangxinxin.w...@huawei.com>; qemu-devel@nongnu.org; > > quint...@redhat.com; Gonglei (Arei) <arei.gong...@huawei.com> > > Subject: Re: [PATCH] migration/fd: abort migration if receive POLLHUP event > >
> > Ah, wait. I just noticed that Xin mentioned about the loop already - > > it's an infinite loop of SIGHUP. I suppose it means that we'll just > > never go into fd_accept_incoming_migration() at all? > > Yeah, that's what I want to fix. > > > > > If so, I'm not sure whether we should just always watch on G_IO_HUP > > (and possibly G_IO_ERR too) in qio_channel_create_watch(): > > > > GSource *ret = klass->io_create_watch(ioc, condition | G_IO_HUP | > > G_IO_ERR); > > > > Otherwise I'm not sure the same loop will happen for other users of > > qio_channel_add_watch(). > > In my scenario, it's clear the client quit immediately and we > never got a POLLIN event, otherwise, > the watch should be unregistered when POLLIN event coming. > As Daniel said, normally G_IO_IN will be the first event, we > need to find why POLLIN event never happened, I'll try it. Yes, I have always been under the belief that you're guaranteed to get a POLLIN event when the client closes the connection, in addition to the POLLHUP event, but it sounds like that is not happening so I guess I'm mistaken in that. In this case, it should be sufficient to just add the G_IO_HUP|G_IO_ERR events when creating the watch - probably no need to add extra code to the fd_accept_incoming_migration() method. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
