Date: Wed, 25 Apr 2012 17:34:05 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Oliver Brandmueller <ob@e-Gitt.NET> Cc: freebsd-stable@freebsd.org Subject: Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak Message-ID: <1587904922.3402243.1335389645650.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120424142751.GV65313@e-Gitt.NET>
next in thread | previous in thread | raw e-mail | index | archive | help
------=_Part_3402242_1883470986.1335389645646 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Oliver Brandmueller wrote: > Hi, > > After figuring an easy way to repeat the behaviour and hunting it down > to the combination of ZFS+newNFS and removal of files or directories I > opened PR kern/167266 > Good work isolating this! I now see the problem. The new NFS server code assumed that VOP_LOOKUP() calls would not set SAVENAME, so it expected the path buffer to be free'd by the nfsvno_namei() when it hadn't set SAVENAME. It turns out ZFS sets SAVENAME in zfs_lookup() for the DELETE case. The attached patch, which is also here, should fix the problem for now: http://people.freebsd.org/~namei-leak.patch Please test this patch and let me know if it fixes the leak. jwd@ is working on a patch that will avoid using uma_zalloc() to get a path buffer for most cases for performance reasons. Once that patch goes it, the code should be patched so that it checks for SAVENAME being set for all cases where uma_zalloc() has allocated a path buffer, so that no more leaks like this will happen when underlying file systems set SAVENAME. rick ------=_Part_3402242_1883470986.1335389645646 Content-Type: text/x-patch; name=namei-leak.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=namei-leak.patch LS0tIGZzL25mc3NlcnZlci9uZnNfbmZzZHBvcnQuYy5zYXYJMjAxMi0wNC0yNSAxNjo1MDowNS4w MDAwMDAwMDAgLTA0MDAKKysrIGZzL25mc3NlcnZlci9uZnNfbmZzZHBvcnQuYwkyMDEyLTA0LTI1 IDE3OjA4OjQzLjAwMDAwMDAwMCAtMDQwMApAQCAtMTA0Nyw2ICsxMDQ3LDggQEAgbmZzdm5vX3Jl bW92ZXN1YihzdHJ1Y3QgbmFtZWlkYXRhICpuZHAsIAogCWVsc2UKIAkJdnB1dChuZHAtPm5pX2R2 cCk7CiAJdnB1dCh2cCk7CisJaWYgKChuZHAtPm5pX2NuZC5jbl9mbGFncyAmIFNBVkVOQU1FKSAh PSAwKQorCQluZnN2bm9fcmVscGF0aGJ1ZihuZHApOwogCU5GU0VYSVRDT0RFKGVycm9yKTsKIAly ZXR1cm4gKGVycm9yKTsKIH0KQEAgLTEwODYsNiArMTA4OCw4IEBAIG91dDoKIAllbHNlCiAJCXZw dXQobmRwLT5uaV9kdnApOwogCXZwdXQodnApOworCWlmICgobmRwLT5uaV9jbmQuY25fZmxhZ3Mg JiBTQVZFTkFNRSkgIT0gMCkKKwkJbmZzdm5vX3JlbHBhdGhidWYobmRwKTsKIAlORlNFWElUQ09E RShlcnJvcik7CiAJcmV0dXJuIChlcnJvcik7CiB9Cg== ------=_Part_3402242_1883470986.1335389645646--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1587904922.3402243.1335389645650.JavaMail.root>