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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
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)
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
