Date: Fri, 5 Mar 2010 17:01:59 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Daniel Braniss <danny@cs.huji.ac.il> 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: <Pine.GSO.4.63.1003051654020.12115@muncher.cs.uoguelph.ca> In-Reply-To: <E1NnS3w-000BXW-HQ@kabab.cs.huji.ac.il> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 5 Mar 2010, Daniel Braniss wrote:
>>
>>
>> On Tue, 2 Mar 2010, Daniel Braniss wrote:
>>
>>>
>>> just keep sending insights/pointers and enjoy life
>>>
>>
>>
>> You could try this patch for sys/rpc/replay.c. Completely untested and
>> just typed into email (so don't give it to "patch", just edit the file).
>>
>> - try adding these 2 lines just before the end of replay_setreply() in
>> sys/rpc/replay.c:
>>
>> - }
>> + } else if (m)
>> + m_freem(m);
>> mtx_unlock(&rc->rc_lock);
>> }
>>
>> It's the only place I can see in replay.c that might leak, rick
>>
> this is what I did:
> --- a/sys/rpc/replay.c Mon Mar 01 18:29:54 2010 +0200
> +++ b/sys/rpc/replay.c Fri Mar 05 09:24:17 2010 +0200
> @@ -243,6 +243,9 @@
> rce->rce_repbody = m;
> if (m)
> rc->rc_size += m_length(m, NULL);
> + } else if (m) {
> + printf("free m=%p ...\n", m);
> + m_freem(m);
> }
> mtx_unlock(&rc->rc_lock);
> }
>
> 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
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.)
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.1003051654020.12115>