xen 4.8.1: xenstore key leak with driver domains

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

xen 4.8.1: xenstore key leak with driver domains

James Dingwall

I am experiencing a problem where xenstore (stubdom and daemon) leak keys when rebooting guests using a network
and/or disk driver domain.  After capturing the content of xenstore before/between/after two guest reboots I
have found that the keys which are not cleaned up are of the form:

/local/domain/1/backend/vbd/31/768/dev = "hda"   (n1,r31)
/local/domain/1/backend/vbd/31/768/type = "phy"   (n1,r31)
/local/domain/1/backend/vbd/31/768/mode = "w"   (n1,r31)
/local/domain/1/backend/vbd/31/768/device-type = "disk"   (n1,r31)
/local/domain/1/backend/vbd/31/768/discard-enable = "1"   (n1,r31)
/local/domain/2/backend/vif/31/0/feature-sg = "1"   (n2,r31)
/local/domain/2/backend/vif/31/0/feature-gso-tcpv4 = "1"   (n2,r31)
/local/domain/2/backend/vif/31/0/feature-gso-tcpv6 = "1"   (n2,r31)
/local/domain/2/backend/vif/31/0/feature-ipv6-csum-offload = "1"   (n2,r31)

domain 1 is the disk driver domain, 2 the network driver domain.  What seems suspicious is the permissions of
these keys which are setup by dom0 when the guest is created (libxl_device.c) but the cleanup is the
responsibility of the driver domain - still using udev to trigger xen-hotplug-cleanup as xl devd reliably
segfaults on a domain shutdown.  Although the hotplug cleanup script tries to remove the path the permissions
prevent this from taking place from the driver domain.  (When the backends are in dom0 there is no problem
because dom0 does not respect a permission n0)

The leak is ~110 keys (guest with stubdom, 2 disks, one vif) per reboot, after ~480 reboots xenstore can no
longer write any new keys and guests can no longer be managed.

Any ideas on the best way to resolve this?


Xen-users mailing list
[hidden email]