Deadlock in the routing code

[Stephen Clark]

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 freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-net
>To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
>  
>
what version of freebsd is this?

-- 

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)