mbuf leakage with nfs/zfs?

[Rick Macklem]

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