> > > 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"