On Mon, 14 Feb 2011, r...@objcomp.com.au wrote:
> There is a code path in rt_senddesync that fails to deallocate an
> mbuf in the case where sbappendaddr fails. If sbappendaddr fails,
> a 200ms timeout is scheduled to retry the operation, but the mbuf
> remains allocated.
>
> The ddb stack trace from a breakpoint set in m_gethdr is:
> m_gethdr(2,1,d9798eb4,d03e292e,30d40) at m_gethdr
> rt_msg1(10,0,d9798ed0,d9798ed4,d0202f0d) at rt_msg1+0x45
> rt_senddesync(d15ed480,d9798f00,d03cbd36,d9798ef4,d1535a80) at
> rt_senddesync+0x2a
> >Fix:
> Free any allocated mbuf prior to calling timeout_add in rt_senddesync.
Thanks, that was very helpful. Does this fix it?
Index: rtsock.c
===================================================================
RCS file: /home/tedu/cvs/src/sys/net/rtsock.c,v
retrieving revision 1.113
diff -u -r1.113 rtsock.c
--- rtsock.c 6 Jan 2011 14:50:11 -0000 1.113
+++ rtsock.c 14 Feb 2011 03:25:54 -0000
@@ -309,6 +309,8 @@
rop->flags &= ~ROUTECB_FLAG_DESYNC;
sorwakeup(rp->rcb_socket);
} else {
+ if (desync_mbuf)
+ m_freem(desync_mbuf);
/* Re-add timeout to try sending msg again */
timeout_add(&rop->timeout, ROUTE_DESYNC_RESEND_TIMEOUT);
}
