>
>
> 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
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
btw, the list of CCs is rather big, so if anyone feels he rather be removed,
please let me know.
cheers,
danny
_______________________________________________
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"
