Hello Andrew, El 10/02/15 a les 10.22, Andrew Thompson ha escrit: > On 10 February 2015 at 16:25, Andrew Thompson <thom...@freebsd.org> wrote: > >> On 9 February 2015 at 23:28, Roger Pau Monné <roger....@citrix.com> wrote: >> A bit of trial and error with dtrace has narrowed this down. I can cause >> the leak by just opening /dev/xen/xenstore >> >> int main() { >> open("/dev/xen/xenstore", O_RDWR, 0); >> } >> >> # vmstat -m | grep xenstore; ./open; vmstat -m | grep xenstore >> xenstore 8739 104797K - 56078 16,32,64,128,256,512 >> xenstore 8740 104809K - 56079 16,32,64,128,256,512 >> >> >> Using dtrace probes I can see that xs_dev_close is never called. >> > > I think I have worked this out. Rackspace use an agent called nova-agent > which keeps and open handle on /dev/xen/xenstore. Since xenstore isnt using > the D_TRACKCLOSE flag it will not call d_close until the last reference is > dropped. Since xenstore expects to malloc/free on open and close this > assumption breaks and will leak memory. > > If i stop nova-agent I can see xs_dev_close being called and the memory > freed with testing with xenstore-read. The correct solution seems to be to > set D_TRACKCLOSE if I understand its purpose correctly.
Thanks for doing all this legwork! IMHO the best solution is to switch xenstore dev to use cdevpriv in order to store each client data. What we are doing right now (storing client data in dev->si_dvr1) is plain wrong. I've uploaded two patches (one for HEAD and one for stable/10) so that you can try it also, please report back whether this fixes your problem or not: https://people.freebsd.org/~royger/xenstore_fix/ Roger. _______________________________________________ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"