[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] "xl restore" leaks a file descriptor?



On Wed, Aug 12, 2015 at 11:04:25AM +0100, Ian Campbell wrote:
[...]
> > > 
> > > As Andy says I think we want restore_fd in the check, I can't see any
> > > reason we wouldn't want to close the socket too.
> > > 
> > 
> > Do you mean migrate_fd when you say "socket"?
> 
> In the migrate case we do "restore_fd = migrate_fd;", so yes, indirectly.
> 
> 
> >  I tried that, but that led
> > to failure because toolstack still needs to get controlling information
> > out of it (the "GO" message).
> > 
> > Maybe I close this too early.
> 
> Right.
> 

I look at the code. Even if we should close that socket, it should not
happen inside create_domain, because the caller (migrate_receive) needs
that fd.

IMO create_domain should only close restore_fd if that fd is opened by
itself.

Whether we should close send_fd and recv_fd in migrate_receive is
another matter. I don't think we should. They are just stdin and stdout,
not closing them wouldn't cause us any trouble.

Wei.

> 
> >  I will have a closer look today.
> > 
> > > For reboot handing you would need to reset the fd to < 0, otherwise 
> > > when we
> > > come back around on reboot we will close this again.
> > > 
> > > Would it be less error prone to put this in the if (restoring) just 
> > > above,
> > > i.e. exactly where restore_fd is used and which already has the reboot
> > > logic in place with restoring = 0.
> > > 
> > 
> > Depending on whether we can close migrate_fd.
> > 
> > Wei.
> > 
> > > Ian.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.