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:



freebsd-xen@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Reply via email to