[Xen-users] xen 4.8.1: xenstore key leak with driver domains

[James Dingwall <james-xen@xxxxxxxxxxxxxx>]

Hi,

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?

Thanks,
James

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-users