Deadlock in the routing code
Stephen.Clark at seclark.us
Thu Dec 13 10:15:24 PST 2007
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 :-).
>freebsd-net at freebsd.org mailing list
>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)
More information about the freebsd-net