Re: xenstored memory leak

[Ian Jackson <ian.jackson@eu.citrix.com>]

Wei Liu writes ("Re: [Xen-devel] xenstored memory leak"):
> On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
> > qemu as the device model is setting up a xenstore watch for each backend
> > type it is supporting. Unfortunately those watches are never removed
> > again. This sums up to the observed memory leak.

I think this must be a bug in C xenstored.

> > I'm not sure how oxenstored is avoiding the problem, may be by testing
> > socket connections to be still alive and so detecting qemu has gone.
> > OTOH this won't help for oxenstored running in another domain than the
> > device model (either due to oxenstore-stubdom, or a driver domain with
> > a qemu based device model).
> 
> How unfortunate.
> 
> My gut feeling is that xenstored shouldn't have the knowledge to
> associate a watch with a "process".

xenstored needs to associate watches with connections.  If a
connection is terminated, the watches need to be cleaned up, along
with whatever other things "belong" to that connection (notably
transactions, and replies in flight).

Here a `connection' might be a socket, or a ring.

C xenstored does have code which tries to do this.  It's a bit
impenetrable, though, because it's done through destructors provided
to the reference counting membery allocator (!)

> The concept of a process is only meaningful to OS, which wouldn't
> work on cross-domain xenstored setup.  Maybe the OS xenbus driver
> should reap all watches on behalf the dead process. This would also
> avoid a crashed QEMU leaking resources.

The OS xenbus driver needs to mediate everything, so that it can
direct replies to the right places etc.  It needs to (and does)
maintain a list of watches.  When a process closes the xenbus device,
it destroys the watches by issuing commands to the actual xenstored
via its ring connection.

I guess that the qemu in this case is making a socket connection to
xenstored.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel