Deadlock in the routing code

Maxime Henrion mux at
Fri Dec 14 07:29:43 PST 2007

Stephen Clark wrote:
> Maxime Henrion wrote:
> >Replying to myself on this one, sorry about that.
> >
> >I said in my previous mail that I didn't know yet what process was
> >holding the lock of the rtentry that the routed process is dealing
> >with in rt_setgate(), and I just could verify that it is held by
> >the swi1: net thread.
> >
> >So, in a nutshell:
> >
> >- The routed process does its business on the routing socket, that ends up
> > calling rt_setgate().  While in rt_setgate() it drops the lock on its
> > rtentry in order to call rtalloc1().  At this point, the routed
> > process hold the gateway route (rtalloc1() returns it locked), and it
> > now tries to re-lock the original rtentry.
> >- At the same time, the swi net thread calls arpresolve() which ends up
> > calling rt_check().  Then rt_check() locks the rtentry, and tries to
> > lock the gateway route.
> >
> >A classical case of deadlock with mutexes because of different locking
> >order.  Now, it's not obvious to me how to fix it :-).
> >
> >Maxime
> >_______________________________________________
> >freebsd-net at mailing list
> >
> >To unsubscribe, send any mail to "freebsd-net-unsubscribe at"
> >
> > 
> >
> what version of freebsd is this?

Oops, forgot that bit of information: RELENG_6 as of a few days
ago; it does include jhb@'s last fix in this area, if that's what
you've been wondering.


More information about the freebsd-net mailing list