Date: Sat, 06 Mar 2010 09:09:57 +0200 From: Daniel Braniss <danny@cs.huji.ac.il> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: stable@freebsd.org, freebsd-fs@freebsd.org, Willem Jan Withagen <wjw@digiware.nl>, =?utf-8?B?RWlyaWsgw5h2ZXJieQ==?= <ltning@anduin.net>, rwatson@freebsd.org, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: mbuf leakage with nfs/zfs? Message-ID: <E1Nno98-000OLZ-SI@kabab.cs.huji.ac.il> In-Reply-To: <Pine.GSO.4.63.1003051654020.12115@muncher.cs.uoguelph.ca> References: <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <E1Nl6VA-000557-D9@kabab.cs.huji.ac.il> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> <4B892918.4080701@digiware.nl> <20100227202105.f31cbef7.gerrit@pmp.uni-hannover.de> <20100227193819.GA60576@icarus.home.lan> <BD8AC9F6-DF96-41F9-8E92-48A4E5606DC7@anduin.net> <4B89943C.70704@digiware.nl> <20100227220310.GA65110@icarus.home.lan> <Pine.GSO.4.63.1003011703100.26054@muncher.cs.uoguelph.ca> <E1NmPHy-0009jy-Dj@kabab.cs.huji.ac.il> <Pine.GSO.4.63.1003041910550.9956@muncher.cs.uoguelph.ca> <E1NnS3w-000BXW-HQ@kabab.cs.huji.ac.il> <Pine.GSO.4.63.1003051654020.12115@muncher.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
[...] > > but it didn't help, it's not triggered > > > > Hmm, well that's the only place I could see in replay.c that could leak > (and it's a pretty straightforward piece of code). This is getting > interesting. Just to confirm where we currently are... > > - replay cache disabled --> no leak > - replay cache enabled (with or without the above patch) --> leak > yes and yes. > I'll take another look, but I doubt the leak is in replay.c so... maybe > a reply from the cache is somehow handled incorrectly and that causes the > leak elsewhere? (Just a random hunch at this point.) > it works ok in 7.2, so it would be interesting to compare changes ... > > Thanks for the explanation on the cache, things are begining to make sense. > > If I understand, the reason for this cache is to prevent re-applying an > > already performed rpc, which could lead to data corruption > > > > Yep, you've got it. It is basically a bandaid for the poor transport > semantics provided by UDP. > > Having fun with this one. Thanks for the help, rick > I'm glad :-) danny
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1Nno98-000OLZ-SI>