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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
